Problem with custom login idea, similar to IsInRole in principal

Problem with custom login idea, similar to IsInRole in principal

Old forum URL: forums.lhotka.net/forums/t/244.aspx


Tommybouy posted on Thursday, June 01, 2006

I am curious what I am doing wrong. I have modified the login process to include getting not only roles but also a list of forms users are able to view that may or may not belong to their role. We have plenty of users that fulfill many roles or may need to do something that their role doesn't include. I created a method called CanViewForm which is similar to IsInRole in that it checks for a string value in a list. The problem is I have created the method as public in the ??principal class and the ??identity class but the method isn't visible using the "Csla.ApplicationContext.User.CanViewForm" format. The IsInRole method overrides a base method whereas mine does not. Is that the cause?

Thanks 

Tom

ajj3085 replied on Thursday, June 01, 2006

The problem is that you're expecting a property which isn't defined in the IPrincipal interface.

To get your custom property, you'll need to cast it to your custom principal.

MyCustomPrincipal prin;

prin = ApplicationContext.User as MyCustomPrincipal;
if ( prin == null ) {
    throw new ApplicationException( "Principal must be MyCustomPrincipal" );
}

if ( prin.CanViewForm( "MyForm" ) ) {
   // Do stuff
}

However, if your user must do something, than by definition that action is allowed under his role.  If you have a group of users which can do X and Y, and another user in that same role must also do Z, then, by denfiition, you should create another role for that user which can do X, Y and Z.

HTH
Andy

Tommybouy replied on Thursday, June 01, 2006

Thx ajj3085, I probably should have mentioned I'm using VB. However I used DirectCast and it did work. Thank you. In our business so many of our clients have completely different setups depending on their size and we would end up creating roles for basically every separate piece of the app. We are trying to avoid that and this method does seem to work fine. Doing it the other way don't you find the number of roles is almost unmanageable?

Tom

ajj3085 replied on Thursday, June 01, 2006

You may end up with a large number of roles to manage, but I would think having a seperate list of which forms a user can access would make things even more complex.  Not only do you have to maintain this list, you also have to figure out the two will interact. 

What if a user gets to a form they can't actually use because they don't have permission to read or write the information the business object presents?

Just my opinion though; if your method works for you, that's really what matters in the end.

Andy

Copyright (c) Marimer LLC