Skip to main content
D
Didi3
Inspiring
April 14, 2012
Answered

Authentication - when is the right time?

  • April 14, 2012
  • 3 replies
  • 1399 views

hi there

I have problems understanding what the DevGuide to CF9 says.

On Page 246 it says:

---

Using the onRequestStart method

This method runs at the beginning of the request. It is useful for user authorization (login handling),

---

and later on the same page

---

User authentication

When an application requires a user to log in, include the authentication code, including the cflogin tag or code that calls this tag, in the onRequestStart method. Doing so ensures that the user is authenticated at the start of each request.

---

So far, I understand it well and I completely agree - it's the way I am implementing my pages, too.

------------------------------------------------------------------------

However, on the same page the manual says:

---

Using the onSessionStart method

This method is useful for initializing session data, such as user settings ...

---

Here my understanding disperses.

On my CF9 server, onSessionStart runs before onRequestStart.

So how can I initialize user settings before the user has logged in, since only the feedback of the authentication authority provides me with the user data?

What did I miss?

-Didix

    This topic has been closed for replies.
    Correct answer Adam Cameron.

    They're not supposed to be taken as three connected statements.  Also the guidance about using <cflogin> in onRequestStart is probably not how one would handle this sort of thing, and is pretty bad advice IMO (often the CF docs are not written by people who use CF, so might know how the functionality works, but not how one would use it).

    If one needs authenticated users, one needs to check whether the user is authenticated at the beginning of every request (so onRequestStart), and if they're not authenticated: do something about it (possibly via <cflogin>, although in reality probably not).  Once the user is authenticated one might store some stuff in the session scope.

    On the other hand, one might not need authentication, but still need to record session settings, which one might set defaults for in onSessionStart.  We store our users' previous search filters in session, so we initialise them in onSessionStart to be sensible defaults, updating them as the user changes them. The session scope is not all about authentication.

    Bear in mind the need to be authenticated might not be ubiquitous on a site.  Consider something like Amazon.  One only needs to log in to see some features of the site.  So onSessionStart might just set session.isLoggedIn = false, so the variable always at least exists to be checked in the situations it's relevant.  This saves having a structKeyExists() check every time one wants to know about the variable.  Then when one opts to login, after a successful login one sets session.isLoggedIn = true (along with stuff like user name, etc). When one is on the "front" side of the site, it doesn't care if one is logged in or not, so the onRequestStart there doesn't bother checking.  However on the back-end it would be checking in onRequestStart, and deflecting to a login screen if not logged in.

    Lastly: some tangential advice.  The <cflogin> system is really a poor-man's solution to this sort of thing, and I'd question the merits of its existence in the language.  It's one of those "only vaguely useful" tags like <cfinsert> or <cftable>.  I've never had a situation in which it's actually been a useful approach to the way I need my application to work.  Don't necessarily force yourself down the road of using that to implement your authentication.

    --

    Adam

    3 replies

    D
    Didi3Author
    Inspiring
    April 14, 2012

    Yep, I got it -- and I agree to all you say!

    Some of the cftags they have added since the beginnings is really only to hype the manual ..

    .. but on the other hand we got a bunch of more power since CF1.5

    -Didi

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    April 14, 2012
    Adam Cameron wrote:

    Lastly: some tangential advice.  The <cflogin> system is really a poor-man's solution to this sort of thing, and I'd question the merits of its existence in the language.

    Didi wrote:

    Some of the cftags they have added since the beginnings is really only to hype the manual ..

    As far as <cflogin> goes, I would strongly disagree. For authentication, this tag is the basis of a well designed security framework. The fact that it is simple doesn't make it "a poor man's solution".

    Everyone in Rembrandt's, Van Gogh's or Picasso's day had access to the same materials as them. It is how they put the materials together that made the difference.

    The designers of Coldfusion can only provide the basic tools to enable you to put an authentication mechanism together. Many developers mistakenly read suggestions in the official documentation to be recommendations. However, here, as in art, there are no hard and fast rules. The result either cuts the mustard, or it does not.

    The tools involved in cflogin authentication include

    <cflogin>

    <cfloginuser>

    loginStorage

    sessionManagement

    setClientCookies

    onRequestStart()

    <cflogout>

    This simplicity is deceptive. Authentication may depend on the type of application, but even for very simple applications, it can be quite a challenge to articulate these elements into a solid authentication mechanism.

    For example, the authentication framework has to log clients in and out, but may not interfere with other business concerns. In my opinion, many developers get it wrong because they are unaware of or underestimate how difficult it is to pull off such requirements.

    D
    Didi3Author
    Inspiring
    April 14, 2012

    BKBK wrote:

    The designers of Coldfusion can only provide the basic tools to enable you to put an authentication mechanism together. Many developers mistakenly read suggestions in the official documentation to be recommendations. However, here, as in art, there are no hard and fast rules. The result either cuts the mustard, or it does not.

    This simplicity is deceptive. Authentication may depend on the type of application, but even for very simple applications, it can be quite a challenge to articulate these elements into a solid authentication mechanism.

    For example, the authentication framework has to log clients in and out, but may not interfere with other business concerns. In my opinion, many developers get it wrong because they are unaware of or underestimate how difficult it is to pull off such requirements.

    partially agreed, too!

    Let me give you some background on my situation.

    I'm sticking with CF since 1.5 when I was still exchanging emails with Jeremy Allaire.

    And I love CF. I produced a lot of code until about CF5.

    I had to implement session management at a time, CF did not have anything about this in its toolbox.

    Then I got sucked up with administration work more and more and only coded few lines.

    Now I'm back and I try to catch up with the new ideas and concepts.

    Yes, I belong to those people who seriously read documentation - and examples - and try to follow the 'rules'.

    And believe me, I have also been googling many many hours to get further.

    My task now was to implement a Shibboleth authentication and after several attempts I finally dumped cflogin.

    Maybe cflogin is a more powerful gadget than I recognize.

    But from where should I know?

    Many developers mistakenly read suggestions in the official documentation to be recommendations.

    From where should I get recommendations if not from Adobe? Where are good real world examples?

    I depend on the material that I can study. Otherwise I need to come up with my own interpretation and ideas.

    So if the cleverness of cflogin is even hidden in Adobe's ressources ... how could I know?

    -Didi

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    April 14, 2012

    Didi wrote:

    Using the onSessionStart method

    This method is useful for initializing session data, such as user settings ...

    You raise a legitimate question. The confusion results more from what the documentation omits than from what it says. It should have added that it is talking about general, pre-authentication user data.

    A
    Adam Cameron.Correct answer
    Inspiring
    April 14, 2012

    They're not supposed to be taken as three connected statements.  Also the guidance about using <cflogin> in onRequestStart is probably not how one would handle this sort of thing, and is pretty bad advice IMO (often the CF docs are not written by people who use CF, so might know how the functionality works, but not how one would use it).

    If one needs authenticated users, one needs to check whether the user is authenticated at the beginning of every request (so onRequestStart), and if they're not authenticated: do something about it (possibly via <cflogin>, although in reality probably not).  Once the user is authenticated one might store some stuff in the session scope.

    On the other hand, one might not need authentication, but still need to record session settings, which one might set defaults for in onSessionStart.  We store our users' previous search filters in session, so we initialise them in onSessionStart to be sensible defaults, updating them as the user changes them. The session scope is not all about authentication.

    Bear in mind the need to be authenticated might not be ubiquitous on a site.  Consider something like Amazon.  One only needs to log in to see some features of the site.  So onSessionStart might just set session.isLoggedIn = false, so the variable always at least exists to be checked in the situations it's relevant.  This saves having a structKeyExists() check every time one wants to know about the variable.  Then when one opts to login, after a successful login one sets session.isLoggedIn = true (along with stuff like user name, etc). When one is on the "front" side of the site, it doesn't care if one is logged in or not, so the onRequestStart there doesn't bother checking.  However on the back-end it would be checking in onRequestStart, and deflecting to a login screen if not logged in.

    Lastly: some tangential advice.  The <cflogin> system is really a poor-man's solution to this sort of thing, and I'd question the merits of its existence in the language.  It's one of those "only vaguely useful" tags like <cfinsert> or <cftable>.  I've never had a situation in which it's actually been a useful approach to the way I need my application to work.  Don't necessarily force yourself down the road of using that to implement your authentication.

    --

    Adam

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices