Thought I would toss this out there as a topic for consideration.
I have developed custom security for my ContentBox implementation. One of my goals in my site is to keep all of the custom code completely confined to custom modules so the core of ContentBox can be more easily upgraded without trying to figure out what custom code exists in directories where it doesn’t belong.
I’m currently on CB v.2.1.0.00122. I know that’s a bit old, but I’ve been working on this for a while and haven’t had the time to upgrade and make any changes that the upgrade will require.
Anyway, the point I wanted to get to is that I feel it would be beneficial for the out-of-the-box ISecurityService and SercurityService.cfc to be altered to fully reference the ISecurityService and Author data types (e.g. contentbox.model.security.ISecurityService and contentbox.model.security.Author instead of just ISecurityService and Author).
The obvious question, of course, is why? As it stands, any custom SecurityService file must be placed within the contentbox.model.security folder for it to work. If you do not place your custom service in said folder, the following are your possible errors:
- If you keep the “ISecurityService” and “Author” return types, the return type would actually be referring to cfcs in your custom SecurityService’s folder.
- If you change the return and argument types to “any,” it will, of course, throw an mismatched datatype error.
- If you change the return and argument types to “contentbox.model.security.ISecurityService” and “contentbox.model.security.Author”, the reference is correct, but you receive an error because the interface doesn’t recognize it as being the correct data type.
So your options are to place your custom SecurityService in a folder that should not be used for custom code, or you can alter the existing SecurityService (so it doesn’t throw an error) and ISecurityService to match the full “contentbox.model.security.*” names - in which case you must remember to make the same change whenever you upgrade ContentBox.
Perhaps the desired method is simply to place your custom SecurityService in the contentbox.model.security folder, but I thought I would put this out there and see what people think.
John
Hi John,
Not a lot of people are doing their own security services. However, the way to do it would be to create it and put it anywhere you like. You then need to override the ContentBox wirebox mapping so yours take precedence. This means you must use the shell application’s Wirebox.cfc configuration file and map your security service as “securityService@cb”. That would then map the object first and ContentBox will use it
Luis,
The way you describe is exactly what I did, rebinding “securityService@cb” to my service in my ModuleConfig.cfc. However, the problem arises with local references in the implemented interface. If you look at the interface - ISecurityService.cfc - you find three return data types “ISecurityService,” one return data type “Author,” and two argument data types “Author.”
By not having a full path in the datatype, the issues I noted arise. It’s the basic concept of component datatypes. If you only specify the datatype by the cfc file name (e.g. Author), then only Author.cfc in the same folder as the custom SecurityService counts as an “Author” data type. If your custom SecurityService is not in the same folder as the ContentBox default SecurityService.cfc and ISecurityService.cfc, then specifying “Author” in your custom SecurityService is actually specifying an “Author.cfc” file in the same folder as your custom security service. Same goes for ISecurityService. Thus, the custom service return type is not the same as specifying “Author” and “ISecurityService” within the contentbox.model.security folder. But, if you change your custom SecurityService’s datatypes to correctly reference “contentbox.model.security.Author” and “contentbox.model.security.ISecurityService,” an error is thrown because the name is not simply “Author” or “ISecurityService,” even though the component reference is indeed pointing to the same Author and ISecurityService referenced by the ISecurityService interface.
I tried adjusting the datatypes in several ways, and the only way to get my custom SecurityService to work was to alter the ISecurityService.cfc interface to fully qualify the paths to the datatypes. I guess another solution would be to map the contentbox.model.security path, but I prefer not to create more maps than is really necessary.
Without mapping, try creating a security service in a different directory than your ISecurityService and Author interface and component.
It’s worth noting - just for those who are interested - that for a long time I simply extended the out-of-the-box SecurityService, overrode a few functions, and bound “securityService@cb” to my custom service. This works as long as you don’t override any of the functions that utilize the component datatypes. The moment I overrode logout(), everything broke because I couldn’t properly return an ISecurityService (because the function is called in the child component, thus “this” no longer refers to the out-of-the-box SecurityService, which is what actually implements the interface - and returning the result of super.logout() likewise returns a reference to the child). I did find it interesting that the extended securityService worked when logout() was only available in the parent. Anyway, this paragraph is just an interesting tidbit.
John
Very interesting indeed.
How about we change the direct Author reference to something like: contentbox.security.IAuthor
instead?