http://coldfusion.com logo
Join Slack
Powered by
Is there any trick to get Lucee to populate the cg...
# lucee
q
Is there any trick to get Lucee to populate the cgi.auth_user variable in the official docker image or with the connector under linux (behind apache)? I see it being populated in the logs and in the debug logs in Tomcat, but can't figure out how to get it to translate to my app. Apache is doing basic auth using the module within the httpd server. I'm trying to implement some auth with keycloak, but having the same issue.
b
I'm fairly sure this works with CommandBox 🙂
On a tomcat install, you prolly need to look for http header directly
actually, glancing at Lucee's source code, it looks like auth_user is hard-coded to blank, lol
I think I have a ticket for that from years ago
Lucee does populate remote_user tho
q
I was just about to look at the source code... didn't get that far 🙂
b
With whatever value comes back from the servlet requests 
getRemoteUser()
method
So, look there
The servlet basically controls that value
q
yeah, remote_user is blank in every situation I've tried as well.
b
Here's my ticket from 4 years ago
fixed in Lucee 6 it seems
(I have the Lucee 5 source up ATM)
Google for that but just generic to Tomcat
There is prolly some valve that will do the equiv of what CommandBox does
If the front end web server does the auth, it sends it back in a header
but back end servers shouldn't trust those by default unless they are behind a trusted proxy. Otherwise, a hacker could just spoof the header!
q
right.
b
X-Remote-User
is the header
q
This would be behind a trusted reverse proxy.
Correct, I'm seeing that header in the tomcat logs. Not sure why I'm not seeing it in the remote_user variable, but I'll see if the 6.0.1 load of lucee fixes it.
thanks for finding that though. Too many moving parts on this project.
b
Here's a valve https://github.com/cedadev/tomcat-remote-user-valve but I feel like this would be a built in Tomcat feature. Maybe not
d
IIRC you need a valve for it, but that was a while ago
b
Yep, and that repo I linked to has a valve that does just that.
I'm just not sure if there's a more "official" one
d
Yeah that's not the one I remember lol
Plus it sounds like tomcat is already logging it?
q
denny -- I'm seeing the auth info show up in the debug logs coming from the connector and/or to the Tomcat HTTP servlet when it's in a container (I wasn't sure if Apache was actually passing it along).
so, I know Tomcat is getting the data. Need to dig in if it's actually parsing it and passing it to Lucee. Figured I'd ask here before I dug in too deep, not that there is a known config value needed in the web.conf or something silly like that to get it to populate.
b
It's not passing it to Lucee 🙂
Just because Tomcat is "getting the data" doesn't mean it's getting it in a manner that it will use it
I assume it's just coming across as a regular HTTP header?
q
nod.
b
Dump out 
getHTTPReauestData()
to confirm
Tomcat (or any servlet for that matter) will not use the header just because it's sitting there.
So tomcat needs to do more than "get" it-- it needs to return it from the servlet request which is where Lucee is looking for it
And that's what that valve does
✅ 1
q
correct, it's coming across in the header in the container. boncode didn't seem to have it in the header debugs, but it had it in the stream (I might be looking at that wrong too, but I saw the username there)
b
Right, so install that valve I sent above
q
10-4
b
That will take the header and treat it as truth
d
The valve is ringing a vague bell but I"m sure it wasn't something by a 3rd party
I remember some stuff for basic auth with undertow but even that is vague
I bet I have some project with the valve tho, maybe a grep will find it
b
Yeah, there may be a valve from Apache-- I just didin't see it after a few minutes of Googling
d
It's ironic because it was common knowledge for me at some point, but somehow that knowledge never got out I guess
Like I remember adding the basic auth for the undertow stuff but not how I did it lol (oh yeah, a map of users and passwords… it does come back I guess)
Does lucee not get all the headers?
b
Lucee does get them, but Lucee doesn't use any headers for the CGI population of remote_user
Copy code
if (key.equals(KeyConstants._remote_user)) return store(key, toString(req.getRemoteUser()));
☝️ That is how Lucee populates the key in the CGI scope
where 
req
is the HTTPServletRequest object
So Lucee just parrots back whatever Tomcat says
So if you want Lucee to see it, you've got to make Tomcat see it
q
ah, and it looks like getRemoteUser() uses the built-in auth system from within Tomcat, not headers from the proxy like some other systems.
b
almost
The spec says it pulls the remote_user CGI var
And Tomcat's built in auth sets that CGI var
I THINK the AJP spec allows the web server to proxy back request attributes and such, but an HTTP proxy isn't capable of directly sending anything other than HTTP headers
q
So, that valve is not quite working with boncode... cgi.remote_user is getting populated with [@Java.Security.Principal], so, it's close, just need to tinker with it to return a string... This is getting me closer, thanks!
b
Oh, I forgot you mentioned BonCode. That may use a request attribute
[@Java.Security.Principal]
is interesting-- I'm not sure what that's supposed to mean, lol
q
looks like it's spitting out the java class instead of returning the string.
b
If you're using the AJP connector, this post claims you can just add an attribute to the connector and you may not need the valve https://stackoverflow.com/questions/13749065/forward-remote-user-to-tomcat-via-ajp-e-g-for-shibboleth
d
Sounds like spring
Copy code
authentication.getPrincipal().getUsername();
q
@bdw429s -- that looks to be the answer that requires the least amount of mucking.
b
🤞
d
And it rings a vague bell too so fingers crossed
q
yeah, this does... removing the valve and trying this one...
there we go. remote_user is populating now. thanks! cgi.auth_user is still blank in 5.x, but that is expected.
👏 2
👍 2
thanks for the help.
d
I'm glad crossing my fingers worked! 😂
q
for those playing at home -- if you do want to go the docker route with a reverse proxy (and not AJP), you will need to rename the headers to NOT use REMOTE_USER or X-REMOTE-USER. Without a valve, the header will get overridden as it comes across. For security sake, make sure you strip the header you do plan on using from any incoming requests before it hits Tomcat.
b
Yeppers, otherwise hackers will just send a remote user HTTP header of "admin" 🙂
ModCFML has the same basic "issue" where headers are allowed to do potentially dangerous things on the back end server, and it's important to not be in an environment where the end user can send any of them through
2 Views
Open in Slack
PreviousNext
Powered by