This morning I woke up to discover about 150 error reports in my mail box. They were all from the blog and all had the same error:
Can not decode string "expires".
The detail said:
The input string is not base64-encoded.
I couldn't even begin to imagine where this code was running, but luckily my report included the tag context. Believe it or not - the error was on the line in BlogCFC that uses cflogon. I realized then that maybe something was wrong with the cookie. Here is the value reported by CGI.http_cookie: (Note, I added a line break or two to spread it out.)
CFAUTHORIZATION_scamdenfamilysourcemorpheusblogforumsApplicationcfmgalleonForums=expires; CFID=4801581; CFTOKEN=2ea533ac501d2554-76BF0F72-AD27-30BB-E2A346EC274560B7; JSESSIONID=7030563869cb7434c484; CFAUTHORIZATION_ebsitescamdenfamilysourcemorpheusblogApplicationcfm_blog_Default=expires
Now I'm not sure where the cfauthorization cookie is coming from. I would have assumed cflogon, however, a test on my local server didn't show the same cookie. Either way - since it is possible for someone to change their cookies, does this mean cflogon can be forced to throw an error just due to a bad cookie? Shouldn't cflogon simply see a bad cookie as an invalid authorization?
I started out as a huge fan of roles based security, but the issues I keep running into really make me think that it may be time to leave it.
Archived Comments
hehe, I really admire your persistence with using CFLOGIN!
Your shared experiences have been invaluable when it comes to CF's approach to this issue and when we are faced with using/supporting it!
"I started out as a huge fan of roles based security, but the issues I keep running into really make me think that it may be time to leave it."
What's your next favorite option?
Persevere Ray, or let the CF team know so they can tighten it up for Scorpio!
fuzie: By hand, the way I did it in the past.
Peter: I'm on that. :)
Funny, I just got the same error from my blog (although only 1...I guess your traffic pattern's different from mine!), but mine says: 'Can not decode string "deleted".' It was also in the cflogin tag, but I haven't had to go dig in and see how to replicate the error. I'm using your latest BlogCFC release. I'm not looking for an "answer" from you, just pointing out that you're not alone.
Funny, I just got the same error from my blog (although only 1...I guess your traffic pattern's different from mine!), but mine says: 'Can not decode string "deleted".' It was also in the cflogin tag, but I haven't had to go dig in and see how to replicate the error. I'm using your latest BlogCFC release. I'm not looking for an "answer" from you, just pointing out that you're not alone.
What if you're only using CFLOGIN with loginStorage="session"? Do you see this same error happening in that confirguration? B/c it looks like this is a cookie problem with using loginStorage="cookie". so maybe the cflogin session storage won't see this error..?
I am using loginStorage="session".
tell me if i'm wrong:
if i use session for the loginstorage, cfauthorization is only found in the session scope. it seems weird to me to find cfauthorization in your cookie if your using loginstorage=session. no?
True - I forgot that. My error handlers isn't dumping session.
Of course, now the error is gone. THe odd thing is that other folks saw it too.
I -did- hear back from my contact at Adobe, so more news may come soon.
interesting issues your having. I did a bit of research into the possibilities of using cflogin or my own homegrown security system as well. I decided to build my own because then I knew exactly how it worked and what to expect from it...I do however like that cflogin ties into the CFC's and can specify which roles have access to what CFC's...my security controls are just above the CFC level so unfortunately I'm not as secure, but to execute pages that use those CFC's, well...thats a whole different issue :)
I just stumbled upon this discussion while looking for help on a similar topic. In my experience, the only way I could get CFLOGIN with loginStorage=Session to work was to force a CFAUTHORIZATION cookie.
<cfparam name="SESSION.CFAUTHORIZATION" default="">
<cfcookie name="CFAUTHORIZATION_#APPLICATION.applicationname#" value="#SESSION.CFAUTHORIZATION#">
I just fell into the same pit. I should have listened to my buddies... what's the point in having 'neat' features if they aren't reliable?
So... my application is nearly completed. I just went back through it to encrypt my passwords before I publish/test it with other people. Now I'm getting the same error.
I'm not using <cfapplication> at all. For the most part, I'm working right out of WACK to handle my authentication and roles.
The good news is... I get to sleep on it until Monday. Hopefully someone here can help me... otherwise it's time to ditch cflogin. *beats head against wall*
This fixed it for me...
<!---Enable session variables for user authentication--->
<cfset this.sessionManagement=true>
<!---Store login info in session--->
<cfset this.loginstorage="session">
What we need here is some code that tests for the sessionCount when a user logs out and the sessionCount when a user timesout.
Any ideas?
I just ran into this in CF9. I have an application with the name 'somename-MG' with the following settings:
<cfset this.sessionManagement = true>
<cfset this.sessionTimeout = createTimeSpan(0,0,10,0)>
<cfset This.loginstorage="session">
I found that when I changed the name of the application by removing the "-" to "somenameMG" it fixed it up.