News Blog - For February 2009
-
OpenID and Auth Updates
The next release will contain full support for OpenID for both normal logins and comments. OpenID can be enabled or disabled per workspace. When enabled, it adds the new custom OpenID javascript selector to the login page.
It also adds support to the comment section. Clicking on Login will popup the OpenID javascript selector.
The authentication system was simplified in the process of adding OpenID. There is a new authentication module called OpenIdAuthenticationModule that can be used along side the existing authentication system built into ASP.NET. Now, authentication is handled consistently across all modes: Basic, WSSE, OpenId, and Forms. The authentication service was no longer needed so it has been removed.
The User domain object now implements IIdentity and is available through HttpContext.User.Identity or Thread.CurrentPrincipal.Identity.
Users in the UserRepository can have multiple id's to support multiple OpenID's for each user.
The AppService domain object was also updated to reference these user id's instead of containing actual AtomPerson domain objects. These updates were propagated to the authorization service. Also, the AtomPerson domain object was updated with an id property so a reference can be made back to the user repository.
Also, the authorization was cleaned up across the AtomPub and Annotation services. The role actions "Annotate", "ApproveEntryOrMedia", and "ApproveAnnotation", are now used in place of AnnotationApprovalMode, EntryApprovalMode, and AnnotatationMode. To control who can annotate and approve, just customize the role matrix. Finally, there is a new setting called AnnotationsOn to allow you to disable annotations regardless of the role matrix.
See the Annotations page for more information.
-
Plug-Ins and Dynamic Controllers
Update: The content of this post is out of date. The concept of plug-ins has since been expanded to support more scenarios, including widgets, plug-ins, and controllers.
The next release contains new support for plug-ins as described in previous posts. Plug-ins are supported using the Dependency Injection framework StructureMap.
The following types are pluggable:
Service Level Plug-ins Default Type Collection Plug-ins Default Type ILogService NLogService IRouteService AtomPubRouteService IController N/A IAtomPubService AtomPubService IUserRepository FileUserRepository IAnnotateService AnnotateService IAppServiceRepository FileAppServiceRepository ICleanContentService XhtmlCleanContentService IAtomEntryRepository FileAtomEntryRepository IMediaRepository FileMediaRepository IAppCategoriesRepository FileAppCategoriesRepository IAuthorizeService ServiceAuthorizeService The Service Level plug-ins can all be controlled using the <StructureMap> configuration section in the web.config file.
The following example shows how to set properties on the blog collection to use the Blog Plug-in:
The RouteService registers routes on the collections first. Then it registers the default routes. Special care must be taken when registering routes so they occur in the correct order. Also, plug-in routes should take care to use the collection constraint so that routes are properly overridden only on collections using the RouteService plug-in.
Controllers are dynamically instantiated using the StructureMap ObjectFactory. Therefore, plug-ins can provide new routes and handle them with new controllers. Currently, new routes are limited to collection plugins that fire the RegisterRoutes event. This will be extended in the future to support routes outside of collections for things such as widgets.
I am currently flushing out the Widget story and I'm leaning towards a combination of techniques using PartialRequests and Modularity. If you have any suggestions for widget support, please leave a comment below.
