User authentication in Mvc
Moderator: General Moderators
Re: User authentication in Mvc
Usually, the reason exceptions are not preferred in most languages is because they tend to be the most inefficient as the system has to do a lot more processing to determine that there is an exception. I say this having not coded in quite a while so I could be wrong with PHP.
Last edited by alvinphp on Thu Feb 28, 2008 12:23 am, edited 1 time in total.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: User authentication in Mvc
Exceptions incur a performance hit in compiled languages like C++ because of the additional overhead required by RTTI (Runtime type information). PHP provides this regardless of whether you want it or not, so you can basically use exceptions OR you don't use exceptions, but you see no direct performance gain if you go with the latter.Usually, the reason exceptions are not preferred in most languages is because tends to be the most inefficient as the system has to do a lot more processing to determine that there is an exception. I say this having not coded in quite a while so I could be way wrong with PHP.
Re: User authentication in Mvc
I will concede and shut up if you give me an example I can't categorize (I realize the fact that I've had none in my experience, doesn't mean there aren't any, I'm open minded about such things, so fire away)arborint wrote:Because, not all programming problems where there is no in-between code to convey data are "exceptional situations". Many are quite expected and some have nothing to do with errors. That is to problem with arguments based on this idea of "exceptional."
The RTTI is only a part of the cost, the major weight comes from the additional stack unwinding code, and I would imagine PHP carries that as well (not that one should overly care about performance in web apps, but still)Hockey wrote:Exceptions incur a performance hit in compiled languages like C++ because of the additional overhead required by RTTI (Runtime type information).
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
Re: User authentication in Mvc
I'm not interested in shutting you up; quite the opposite!
Imagine you have blog software (not hard to imagine, really) and your "post" controller has a "create" action. It would be reasonable to expect that the user has logged in to get to this point, otherwise they wouldn't be submitting a form to create a post.
So in this case, your normal program flow would check to see that the post details are valid. Ideally, the model would validate the data you're trying to create a record for, but I digress. Anyway... so what if the user isn't logged in? Is this something you should check at every step of the execution? I'd prefer to throw a UserNotLoggedIn exception that can be rescued with a custom template:
"you must be logged in to attempt this action >> [login form]" which redirects to the previous URI with the previous request data.
It's clean and DRY, and it still seems to adhere to the "exceptional" condition in a sense.
What do you guys think? Would this be an appropriate use of exceptions?
Also, what if your user session times out? Is that an exceptional situation? Obviously you'd be checking this in a before filter, but it seems like an exception is a good place to bundle the error handling, grouped by the type of error.
Imagine you have blog software (not hard to imagine, really) and your "post" controller has a "create" action. It would be reasonable to expect that the user has logged in to get to this point, otherwise they wouldn't be submitting a form to create a post.
So in this case, your normal program flow would check to see that the post details are valid. Ideally, the model would validate the data you're trying to create a record for, but I digress. Anyway... so what if the user isn't logged in? Is this something you should check at every step of the execution? I'd prefer to throw a UserNotLoggedIn exception that can be rescued with a custom template:
"you must be logged in to attempt this action >> [login form]" which redirects to the previous URI with the previous request data.
It's clean and DRY, and it still seems to adhere to the "exceptional" condition in a sense.
What do you guys think? Would this be an appropriate use of exceptions?
Also, what if your user session times out? Is that an exceptional situation? Obviously you'd be checking this in a before filter, but it seems like an exception is a good place to bundle the error handling, grouped by the type of error.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: User authentication in Mvc
So you are considering a cross-cutting concern to be something where there is not in-between code to handle the communication. In this case from the requested controller doesn't know anything about the login controller -- only "I'm not logged-in" and the exception to raise. The requested controller could forward, but that would require knowledge of the login controller.
(#10850)
Re: User authentication in Mvc
The same module that is responsible for determining if the user is logged in should care about what to do if he's not. It is possible for the current controller to pass controller-dependant data, for example an URL to redirect to if not logged in.
You are in fact doing the same (as far as I get it), only instead of using regular function calls, you throw it on one end and catch it on another. Even if you had interchangeable login modules (so whichever is used would have caught the exception), you can still 'polymorphically' call whichever is used.
@arborint:
Note that this doesn't introduce additional dependancies, as they are already there - the current controller already "knows" about the login module (since it uses it to check the login status, authorization levels, whatever)
You are in fact doing the same (as far as I get it), only instead of using regular function calls, you throw it on one end and catch it on another. Even if you had interchangeable login modules (so whichever is used would have caught the exception), you can still 'polymorphically' call whichever is used.
@arborint:
Note that this doesn't introduce additional dependancies, as they are already there - the current controller already "knows" about the login module (since it uses it to check the login status, authorization levels, whatever)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: User authentication in Mvc
In my code the current controller knows nothing about the "login module" (not sure exactly what "module" means in this sense). The controller knows a little about the Access Control needs, but nothing about the Authentication needs.Mordred wrote:@arborint:
Note that this doesn't introduce additional dependancies, as they are already there - the current controller already "knows" about the login module (since it uses it to check the login status, authorization levels, whatever)
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: User authentication in Mvc
Ditto.arborint wrote:In my code the current controller knows nothing about the "login module" (not sure exactly what "module" means in this sense). The controller knows a little about the Access Control needs, but nothing about the Authentication needs.Mordred wrote:@arborint:
Note that this doesn't introduce additional dependancies, as they are already there - the current controller already "knows" about the login module (since it uses it to check the login status, authorization levels, whatever)
Re: User authentication in Mvc
I was speaking about Kieran's imaginary blog, I don't know about yout system - do you use exceptions for managing failed authorization as well?
Sorry about the "module", I must keep forcing myself into thinking in MVC terminology. So your current controller knows "a bit" about authorization (access control). What exactly? A reference to an AC model object that can be asked about access rights to the functionality of the current model? Displaying "failed authorization" messages looks like a matter for the current controller, eventually with a callback to the AC model so it can be notified of the failure. I still see well-defined roles with no need for "calls to the unknown recipient" (which is essentially what you seem to use exceptions for). It's like throwing messages in the ocean
Sorry about the "module", I must keep forcing myself into thinking in MVC terminology. So your current controller knows "a bit" about authorization (access control). What exactly? A reference to an AC model object that can be asked about access rights to the functionality of the current model? Displaying "failed authorization" messages looks like a matter for the current controller, eventually with a callback to the AC model so it can be notified of the failure. I still see well-defined roles with no need for "calls to the unknown recipient" (which is essentially what you seem to use exceptions for). It's like throwing messages in the ocean
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: User authentication in Mvc
Typically I would handle all of that in the Front Controller. The Controller (Action Controller) would only provide a method or parameter that specifies who/what is allowed/denied -- if it is not defined externally by module/action name. The FC would get the data before dispatch to see if it should dispatch. I don't know how pertinent this is to this discussion.
(#10850)