A Galleon Forums user alerted me to an issue today that I thought I’d share with folks. He noticed that everytime he would try to post a new thread, he would get an error. Everything else seemed to work ok, but anything involving a form, in this case posting a new thread or trying to use the admin, would fail.
Turns out, he was using IIS Basic Authentication on the web server. Galleon makes use of CFLOGON to handle security. It doesn’t force you to logon. Instead, it lets you browse the site, and when you want to write a message, you need to register or logon. In order to handle this logic, I wrote a simple UDF:
return getAuthUser() neq "";
The idea was that - when you logged in, getAuthUser would equal your username. Anyone logged in to the system would have the rights to post content.
However, the CFLOGIN system also integrates with your web server security. What happaned was that getAuthUser was not blank, but equaled the username used by IIS when he was first prompted to login.
So, Galleon thought he was logged in. It provided him with a button to enter a new thread. However, the CFC used ROLEs restrictions, and would not let him post.
Just so it is clear, this is not a bug. This stems from the fact that my application was saying he was logged in when he was not. I believe if I simply tweak my UDF, I won’t have the problem anymore, although I’m curious as to what getAuthUser will return since there will be both an IIS-level user and a Galleon level user.
I will probably simply set a session variable, and then have my UDF check for that. Now I know that flies in the face of things I’ve said (and others) about directly accessing “external” scopes in UDFs. However, this is a perfect example (imho) of where the rules were mean’t to be broken.
At the same time, it would be nice if MACR would add a isAuthenticated() function!