[cyb1n]

I have a web site with a custom coded content management system. Lately I've been having some trouble with the login framework surrounding the content management pages. Occasionally when a user logs in they will not have access to the elements they should based on their permissions; additionally, users will occasionally open the content management pages to find that they are logged in as another user (sometimes with full administrator access). The workstations are not shared so I know it is not a simple matter of a persisting session. The site uses an Application CFC, cfinclude for the Login Page, invoked CFC to check user credentials and log the user in, and a Master Page for the layout which was created using a custom tag which wraps the page content with a header, nav menu, and footer. If anyone might be able to shed some light on where these problems might be generated it would very helpful. Below you'll find the code snippets for the Login Page and Login CFC, if additional code snippets are required to determine the source of the bug please let me know.

Login Page (used as an include):

<script type="text/javascript">
	$(document).ready(function() {
	   $('input[type="submit"]').button();
	   $('.button').button();
	});
</script>

<cfif isDefined('form.login')>
    <cfinvoke component="#application.cfcPath#.login" method="onLogin" returnvariable="sTrack">
    	<cfinvokeargument name="u" value="#form.user#" />
        <cfinvokeargument name="p" value="#encrypt(form.pass, application.cryptkey, 'AES', 'HEX')#" />
    </cfinvoke>

	<cfif isDefined('session.cfauthorization_floridastateparks')>    
	    <cflocation url="#application.baseHref#admin2/default.cfm" addtoken="true" />
        </cfif>

    
<cfelseif isDefined('url.logout')>
    <cfinvoke component="#application.cfcPath#.login" method="onLogout" />
    <cflocation url="default.cfm" addtoken="true" />
</cfif>

<cfif isDefined('session.cfauthorization_floridastateparks')>
<cfoutput>
<div style="height:35px;">
<span style="float:left;padding-top:5px;padding-left:10px;">Logged in as: #getAuthUser()#</span>
<a class="button" href="?#session.URLToken#&logout" style="float:right;">Logout</a>
<a class="button" href="#application.basehref#admin2/?#session.URLToken#" style="float:right;">Home</a>
</div>
</cfoutput>
<cfelse>
<div style="background:#fff;margin:3px auto;padding:5px 2px;text-align:center;width:186px;">
    <cfif isDefined('sTrack')>
    	<cfdump var="#sTrack#" />
    </cfif>
    
	<cfform action="#cgi.script_name#" id="form-login" method="post" name="form-login">
    	<label for="user" style="display:inline;">Username:</label>
        <cfinput id="user" name="user" style="display:inline;width:180px;" type="text" />
        
        <label for="pass" style="display:inline;">Password:</label>
        <cfinput id="pass" name="pass" style="display:inline;width:180px;" type="password" />
        
        <cfinput id="login" name="login" type="submit" value="Login" />
    </cfform>
</div>
</cfif>

Login CFC (invoked by Login Page):

<cfcomponent>
	<cffunction name="onLogin" output="true" returntype="string">
    	<cfargument name="u" required="yes" />
        <cfargument name="p" required="yes" />
        
        <cfset var sTrack = '' />

		<!--- Orcale stored procedure call --->
		<cfset proc = "OPGDB.PKG_ADMIN2.GET_USER">
		<cfstoredproc procedure="#proc#" datasource="#application.gds#">  
			<cfprocparam cfsqltype="cf_sql_varchar" value="#u#">  
			<cfprocresult name="qUser">      
		</cfstoredproc>	    

    
        <cfif qUser.recordCount GT 0>
			<!--- Orcale stored procedure call --->
			<cfset proce = "OPGDB.PKG_ADMIN2.CHECK_USER">
			<cfstoredproc procedure="#proce#" datasource="#application.gds#">  
				<cfprocparam cfsqltype="cf_sql_integer" value="#qUser.USERS_KEY#">  
				<cfprocparam cfsqltype="cf_sql_varchar" value="#qUser.user_name#">
				<cfprocparam cfsqltype="cf_sql_varchar" value="#p#">
				<cfprocresult name="qPass">      
			</cfstoredproc>	 
		
          
            <cfif qPass.recordCount GT 0>
                <cflogin>
                	<cfloginuser name="#qUser.user_name#" password="#qPass.password#" roles="#replace(qPass.district & qPass.park & qPass.content, '::', ':', 'all')#" />
                </cflogin>
                
            <cfelse>
                <cfset sTrack = 'Password does not match' />
            </cfif>

        <cfelse>
        	<cfset sTrack = 'Username could not be found' />
        </cfif>
        

        <cfreturn sTrack />
    </cffunction>

    <cffunction name="onLogout">
        <cflogout />
        <cflocation url="#application.baseHref#admin2/default.cfm" addtoken="no" />
    </cffunction>
    
</cfcomponent>

[Craig328]

Well, think on it a moment. The issue you have is that whatever/however you're determining whether a person has access to a page and what level of user they are isn't quite right. So, the container for the user credentials is where you want to start. If it's me, I'm setting that in a struct in the session scope at login and then have the pages or nav menus of what have you reference that (something like session.user.accessLevel).

So, first step is to recreate the problem in your test environment and then once you're reliably getting it to do that, cfdump the container holding the user session vars and see what you have in there. My guess is that you'll find that there's a hole in your logic somewhere in the setting/maintaining of the user's credentials.

Good luck!

[cyb1n]

Thanks, I originally tried writing a custom login function which stored user variables in a struct in the session; however, I ran into the same issue where one user could gain access to another account. Since I was on a time crunch to have a working login framework for the project I resorted to using coldfusion's built in function (cflogin & cfloginuser) which was working fine up until a week ago when the problem resurfaced (only this time while in production). I'm wondering if setting and tracking cookies might help limit the possibility of usurping another user's session, but I haven't had a whole lot of experience with cookies. I've mostly relied on sessions to manage everything as I have never had a need for settings or data to persist after a session has been closed.

[Craig328]

With your problem, is it more of an issue of the server thinking user A is actually user B (that is, the server thinks "Joe" is now "Tom") in all respects or just some of the credentials? It's hard to troubleshoot the particulars of your issue and I don't rely on cflogin or cfloginuser as I like to know what exactly is going on in my app...but I get it that time constraints sometimes forces decisions.

Try and comment out the cflogin and cfloginsuser stuff and build your own session management/identity container and see if you can get your app to work with that. Using cookies may also work depending on how much info you're storing. If it's a low traffic site you might could get away with storing just the user ID and then doing a quick query to the database for credentials for each page request. That's not normally the recommended way of doing it as it increases database interactions but if it's a low traffic site it shouldn't pose a huge problem and it would allow you to get a direct grip on what's happening on each request.

Good luck!

[cyb1n]

The site is a fairly high traffic web site 300,000+ visitors a day; however, there are only about 170 users with login access. The problem has been a little difficult to pinpoint because it isn't really consistent. The framework works as intended 90% of the time, the other 10% may follow some of these examples: A, B & C are logged into the site; A clicks a link and is suddenly logged in as C or B ends their session (usually by just closing the browser) and D logs in and picks up B's session.

[Craig328]

Ah.

That sounds like a locking issue then. Depending on where the confusion is occurring in your code you may want to single thread the access to the part that determines who can do/see what. You can throw a cflock around the entire code block and give it a type=exclusive that ensures that the thread that enters the locked block is the only thread accessing it thus ensuring you're not getting crossover for other user sessions.

If you decide to try that be aware that cflocking a block will create a processing bottleneck and threads accessing that block will start to queue if the block isn't processing quickly. Depending on what you'd be restricting single thread access to though, this could fix your issue.

[cyb1n]

Thanks for the help Craig. I put a cflock around the cfinvoke block on the login page and it seems to have done the trick.

[Craig328]

N/P. Glad I could help.