Zen and the art of Castle maintenance

Great screen cast! Thanks for sharing it. Any chance we’ll get to see more of these from you in the future?

Shane

What topic?

Great screen cast, however the sound quality is too low it would be much much better is you speak louder :)

Lets see if I can put together a wish list of things I’ve researched lately that would have benefited from a screencast…

*Repository pattern using ActiveRecord.
*Advanced usages of Windsor/MicroKernel with plenty of time doing facilities and advanced customization.
*Example of (near) production quality Authentication/Authorization of controllers/actions using filters in MonoRail.
*Neat usages of Dynamic Proxy.

This one is a nice to have:
*Live coding session of donjon.

Shane

@Shanebush: I’ve just posted an article on the subject of authorization and authentication with monorail filters and a custom attribute to mark controller actions. Take a look at part 6 of my series here:

http://pixelbugs.wordpress.com/2008/05/26/6-adding-security/

Or you can use the built in security of .NET with the following (depending on your needs):

http://www.castleproject.org/monorail/documentation/trunk/usersguide/authentication.html
http://www.castleproject.org/monorail/documentation/trunk/viewcomponents/security.html

Hope that helps.

@Andy:
Holy passwords Batman! Thanks for that link. I’ll review it post-haste!

My implementation is pretty much straight out of the userguide that you link to. Saving custom IPrincipal to Session. Haven’t worked out yet how to to use cookies to store FormsAuthenticationTicket and retrieve it correctly in the Filter. I know I’m missing something stupid. Now that I’m inspired again to look at it; if I can’t get it working, maybe I’ll post about it in the forums.

Thanks again for the link though!

Here’s the way I want it to work btw:
Upon login/authentication, a User object is serialized (very small class that implements IPrincipal) into the userdata of a FormsAuthenticationTicket. Call encrypt on ticket, and store it as cookie. Then redirect to calling page.

Calling page executes filter, checks for cookie, if there, reads/unencrypts ticket/deserializes userdata as ‘user’ and sets context.CurrentUser = user; and System.Threading.Thread.CurrentPrincipal = user;

The top part up there is working great. The 2nd paragraph is where I’m having some issues. Any advice on whether this is a good approach or not?

@hammett: Sorry for hijacking the blog comments!

“*Repository pattern using ActiveRecord.”

I’d love a screencast on this one. And by the way, thanks for this current screencast, hammett. Came at the perfect time. I was trying to figure out Windsor auto-registration.

Great screen cast! I like that you show how to use MR without endless sessions of config file tweaking.

I, too, hope to see more screen casts. For beginners MR (and the rest of the castle stack) is quite a massive API. It would therefore be cool if you’d show some best practices you would suggest when dealing with common problems in MR/castle. Some kind of cook book as a guidance.

Regards,
Andre

I see difference with this screencast:

Me) Routing Module finded in Castle.MonoRail.Framework

Screencast)Routing is in Castle.MonoRail.Framework.Routing.RoutingEx

Why? I used RC3.

Get a recent build from builds.castleproject.org

[...] MR and Windsor set up screencast – I am not familiar with Binsor just yet this video does help. [...]