We are currently migrating from ACF9 to Lucee.
We are running into an issue where the value of CGI.REMOTE_USER is set to
an empty string. I found this out by dumping all of the CGI variables.
This is our code:
<!--- Show login as user link for certain underwriters --->
<cfif CGI.REMOTE_USER EQ "ddd" OR CGI.REMOTE_USER EQ "sll" OR
CGI.REMOTE_USER EQ
"bjh" OR CGI.REMOTE_USER EQ "mlt" OR CGI.REMOTE_USER EQ "jrb">
As you can see, it is doing a simple check of the CGI.REMOTE_USER variable,
and then allowing login based on the user ID later in the code.
We currently have an .htaccess file set up in the directory where we are
checking the remote user. Does that affect the way we need to check for
CGI.REMOTE_USER?
What is the best way to retrieve the login user ID when access is
restricted by an .htaccess file?
Thanks for all of your help in advance!
Is it anywhere else in your HTTP headers? You can use GetHttpRequestData() to check.
It might be getting lost in translation between the http proxy and tomcat too. Not sure where that info comes from, but might be worthwhile to check if using an AJP proxy instead of HTTP would make a difference.
I should mention that we are using the htaccess file to grab the list of
user values.
We were able to identify that Apache is holding all of the environment
variables and that somewhere in between Apache communicating with Tomcat,
the variables are being lost.On Monday, May 16, 2016 at 8:44:31 AM UTC-5, Josh Beach wrote:
No, it wasn’t in the HTTP headers. If we are running the site on SSL, will
the AJP proxy need to be configured in the https conf file? Do you have an
example of how that would need to be configured?
Thanks!
On Friday, May 13, 2016 at 2:55:05 PM UTC-5, Jordan Michaels wrote:
Is it anywhere else in your HTTP headers? You can use
GetHttpRequestData() to check.
It might be getting lost in translation between the http proxy and tomcat
too. Not sure where that info comes from, but might be worthwhile to check
if using an AJP proxy instead of HTTP would make a difference.
–
Kind regards,
Jordan Michaels
Vivio Technologies
----- Original Message -----
From: “Josh Beach” josh.r...@gmail.com
To: “Lucee” lu...@googlegroups.com
Sent: Friday, May 13, 2016 9:32:05 AM
Subject: [Lucee] Lucee 4.5 CGI.REMOTE_USER is empty string
We are currently migrating from ACF9 to Lucee.
We are running into an issue where the value of CGI.REMOTE_USER is set to
an empty string. I found this out by dumping all of the CGI variables.
This is our code:
<cfif CGI.REMOTE_USER EQ “ddd” OR CGI.REMOTE_USER EQ “sll” OR
CGI.REMOTE_USER EQ
“bjh” OR CGI.REMOTE_USER EQ “mlt” OR CGI.REMOTE_USER EQ “jrb”>
As you can see, it is doing a simple check of the CGI.REMOTE_USER
variable,
and then allowing login based on the user ID later in the code.
We currently have an .htaccess file set up in the directory where we are
checking the remote user. Does that affect the way we need to check for
CGI.REMOTE_USER?
What is the best way to retrieve the login user ID when access is
restricted by an htaccess file?
Thanks for all of your help in advance!
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/00f54bd2-56a6-484b-b060-ce8358803a99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: examples: I wrote documentation for Railo several years ago that talks about the different connection methods between Apache and Tomcat.
By default the Railo and Lucee installers use mod_proxy_html because it is universally available on the supported Linux distros (RHEL/CentOS & Debian/Ubuntu), it’s fast, and it’s functional enough to cover 95% of what most users need. I talk about two alternatives, mod_proxy_ajp and mod_jk, here:
http://docs.lucee.org/guides/Various/installation-installer-documentation/lucee-server-adminstration-linux/adding-new-site.html
Mark Thomas, Lead Dev for Tomcat, also talks about them here:
http://www.tomcatexpert.com/blog/2010/06/16/deciding-between-modjk-modproxyhttp-and-modproxyajp
If you used the installer and have mod_proxy_html configured, it would probably be easiest to switch to mod_proxy_ajp - which is as simple as replacing the existing “http” values with “ajp” once mod_proxy_ajp is installed into Apache.
No, it wasn’t in the HTTP headers. If we are running the site on SSL, will
the AJP proxy need to be configured in the https conf file? Do you have an
example of how that would need to be configured?
Thanks!
this is a part of what I have inside <location>
RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1]
RequestHeader set X_ISRW_PROXY_AUTH_USER %{RU}e
RequestHeader set AUTH_USER %{RU}e
RequestHeader set REMOTE_USER %{RU}e
Not sure if this will work with out the Single Sign On modules I have added
Hi, I wanted to update this old thread with more information in case somebody else has this problem in the future.
We were having a similar problem upon trying to move our production intranet from Railo to Lucee. In our case, we run on IIS, and we rely on Windows-Integrated (aka NTLM) authentication for our intranet; like the OP, we were finding CGI.Remote_User blank in Lucee even if we could confirm the user had authenticated with IIS.
The issue appears to be an architectural one with the Boncode connector, or more specifically with the AJP protocal implemented by the Boncode connector. The Boncode docs acknowledge this issue relating to CGI.Path_Info: “Using an AJP based connector, like the BonCode connector, you have many advantages, including binary transfer of data, efficient reuse of connections, and SSL data support. However, one of the elements that causes repeated hiccups is the use of the PATH_INFO CGI variable. The AJP protocol currently does not have a method to transfer this information to Apache Tomcat in a native format. Thus references to request.getPathInfo() or CGI.PATH_INFO will return null or empty string in all cases.”
Maybe I’m wrong, but I’m guessing this issue with REMOTE_USER is related to the same problem.
Whether that’s true or not, the problem was solved by using a different method to connect the web server to Lucee. In our case we installed the ISAPI Redirector (which was the method used with our previous version of Railo) and all was well.
1 Like
This isn’t an issue with the BonCode Connector or with Lucee, You need to set tomcatAuthentication= false within the AJP Connector section in the server.xml in Tomcat. Once you do that, you’ll be able to see the CGI.AUTH_USER or CGI.REMOTE_USER variables using the Boncode connector within Lucee.
1 Like