Track the current logged in user

[chris]

Hello!

I was wondering how people are passing the id of a current (logged in)
user using ColdFusion On Wheels.

There are 2 choices that I see:
1) In the controller, calling session.currentuser.id - where
currentuser is a User struct
or
2) Passing the user id in the URL using a route: /conrtroller/[userid]/
action/[id_of_row_for_action]

I'm not too thrilled with accessing Session variables in the
controller, but I'm not thrilled with passing the Id in the URL
either.

So, I was curious as to how others are accomplishing this. I'm open to
other choices.

Thanks,
Chris

[Chris Peters]

In an app that I'm building, I run everything through a filter called authentication in the init() of Controller.cfc:

<cffunction name="init" hint="Provides filtering of admin authentication for all controllers that extend this one. NOTE: When overriding this method, be sure to call super.init(), or else you'll lose all authentication in your new controller.">
       
        <!--- Make sure user is logged in unless they're in the process of logging in --->
        <cfset filters(through="authenticate", except="login,signin,forgot,reset")>
        <!--- Check to see if user needs to reset password before proceeding --->
        <cfset filters(through="checkForPasswordReset", except="login,logout,signin,forgot,reset,password,changePassword")>
        <!--- Only allow access to password reset functionality if settings allow it --->
        <cfset filters(through="restrictReset", only="forgot,reset")>
   
    </cffunction>

Here's what my authenticate() filter looks like in the same Controller.cfc file:

<cffunction name="authenticate" hint="FILTER: Makes sure a user session exists. If not, redirects to login.">
       
            <!--- Make sure user is logged in --->
            <cfif not isLoggedInAdmin()>
                <cfset redirectTo(controller="main", action="login")>
                <cfset loggedInAdminUser = false>
            <!--- If user is logged in, set the properties the layout needs --->
            <cfelse>
                <cfset loggedInAdminUser = model('adminUser').findByKey(session.adminUser.id)>
            </cfif>
   
    </cffunction>

As you can see, I'm using session.adminUser.id to set a variable called loggedInAdminUser, which can basically be used anywhere.

There isn't any problem with accessing the session scope in your controller. In fact, the controller is theoretically the only place that should be accessing the session scope at all.

Hopefully this will give you a start.

[chris]

Chris,

Thanks for the reply! That helps me to understand it more.

You mentioned that the controller is theoretically the only place that
should access the session scope.
I have a variable, session.currentuser sprinkled in my layout - to get
things like user.first_name, etc.

Can you recommend a better way? Or is this fine?

Thanks again,
Chris

[Chris Peters]

I always think of session and application scopes as other "sources of data" like a database, so I'd strictly keep access to them in the controller.

Think about the main benefit: you can change things like how the logged-in user is persisted in the future without needing to change anything in your view code. You would be able to isolate changes to just your controllers, whose jobs are to coordinate with different sources of data.

You'll probably want to add a filter like mine in the parent Controller.cfc's init() method. It can set the variable used site-wide. Just remember that any of your controllers that extend it and implement their own init() methods will need to extend by calling super.init() in the child controller:

<!--- Say.cfc -->
<cfcomponent extends="Controller">
    <cffunction name="init">
        <!--- Needs to call parent constructor --->
        <cfset super.init()>
        <!--- ... Rest of your constructor code here ... --->
    </cffunction>
</cfcomponent>

It's also not generally a good idea to store a full object in the session scope. Think about it: if you needed to change that object, there's no good way of updating those instances in everyone's sessions without restarting the server (which would then cause everyone to lose their sessions).

[chris]

Chris,

Thanks again for responding. Your explanation helps a lot!
I don't think that I've ever thought of the Application and Session as
a data
source, but it makes a lot of sense.

I'll keep you posted if I run into more issues.

Thanks again,
Chris

On Sep 2, 8:11 am, Chris Peters <ch...@clearcrystalmedia.com> wrote:
> I always think of session and application scopes as other "sources of data"
> like a database, so I'd strictly keep access to them in the controller.
>
> Think about the main benefit: you can change things like how the logged-in
> user is persisted in the future without needing to change anything in your
> view code. You would be able to isolate changes to just your controllers,
> whose jobs are to coordinate with different sources of data.
>
> You'll probably want to add a filter like mine in the parent
> Controller.cfc's init() method. It can set the variable used site-wide. Just
> remember that any of your controllers that extend it and implement their own
> init() methods will need to extend by calling super.init() in the child
> controller:
>
> <!--- Say.cfc -->
> <cfcomponent extends="Controller">
>     <cffunction name="init">
>         <!--- Needs to call parent constructor --->
>         <cfset super.init()>
>         <!--- ... Rest of your constructor code here ... --->
>     </cffunction>
> </cfcomponent>
>
> It's also not generally a good idea to store a full object in the session
> scope. Think about it: if you needed to change that object, there's no good
> way of updating those instances in everyone's sessions without restarting
> the server (which would then cause everyone to lose their sessions).
>

[Chris Peters]

Maybe "data source" isn't the right terminology, but I do think of it as a place that stores data semi-persistently. Either way, I'm glad to have helped get the idea across. :D