We have OOD setup so that users log in using Shibboleth, together with a custom missing_home_directory.html page. This has been working without problems for some time. We now have a case where a user is directed to the SSO page, and after logging in, when they expect to get the dashboard, they instead get an error message: Error -- failed to map user (<username>)
I have checked logs for this username on the OOD server and all I can find are typical apache logs of the form "GET /pun/sys/dashboard HTTP/1.1" 404 44 ..." in the access logs (and nothing in the error logs). We have confirmed that this user is able to login to the cluster as expected (using the same account). The only difference I’ve noticed between this user and the accounts for which login is working, is that the username contains a hyphen in this case. It is possible that OOD is not handling this character? What else should I check?
The hyphen could be throwing it off. Do you use a user_map_cmd with /opt/ood/ood_auth_map/bin/ood_auth_map.regex in ood_portal.yml?
If so, let us know what the regex you use.
I don’t believe the default example of \w+ would correctly map hyphenated users. If my hunch is correct here are a couple options:
# \w+ grabs evertying _after_ the hyphen. no user 'o', want to map to 'jeff-o'
irb(main):001:0> /(\w+)@osc.edu/.match("jeff-o@osc.edu")
=> #<MatchData "o@osc.edu" 1:"o">
# this could work well, \w may work with latin characters well (as a pose to using [A-Za-z-])
irb(main):002:0> /([\w-]+)@osc.edu/.match("jeff-o@osc.edu")
=> #<MatchData "jeff-o@osc.edu" 1:"jeff-o">
# .+ may be a bit _too_ inclusive but would automatically pick up the next user
# to say, have an underscore like 'jeff_o'.
irb(main):003:0> /(.+)@osc.edu/.match("jeff-o@osc.edu")
=> #<MatchData "jeff-o@osc.edu" 1:"jeff-o">
Although the solution above has been working, it generates warnings in the Apache logs for every login:
/opt/ood/ood_auth_map/bin/ood_auth_map.regex:54: warning: character class has ‘-’ without escape: /^([A-Za-z0-9-_]+)@xxxx.edu/
I thought this could be resolved by adding the necessary escape, and tested my guess by:
$ /opt/ood/ood_auth_map/bin/ood_auth_map.regex --regex=‘^([A-Za-z0-9-_]+)@xxxx.edu’ ‘test-name@xxxx.edu’
/opt/ood/ood_auth_map/bin/ood_auth_map.regex:54: warning: character class has ‘-’ without escape: /^([A-Za-z0-9-_]+)@xxxx.edu/
/opt/ood/ood_auth_map/lib/ood_auth_map/helpers.rb:35: warning: character class has ‘-’ without escape: /^([A-Za-z0-9-_]+)@xxxx.edu/
test-name
However, making this change in ood_portal.yml (adding the ‘\’ in user_map_cmd), and then running /opt/ood/ood-portal-generator/sbin/update_ood_portal, gives the error:
(/etc/ood/config/ood_portal.yml): found unknown escape character while parsing a quoted scalar at line 114 column 15
Run ‘update_ood_portal --help’ to see a full list of available options.
Since there is further processing before /opt/ood/ood_auth_map/bin/ood_auth_map.regex gets called, I thought double-escape might be needed, so tried changing the pattern in ood_portal.yml to '^([A-Za-z0-9\\-_]+)@xxxx.edu'. With this value, /opt/ood/ood-portal-generator/sbin/update_ood_portal runs, and the file /opt/rh/httpd24/root/etc/httpd/conf.d/ood-portal.conf (after copying ood-portal.conf.new to it) ends up with the pattern '^([A-Za-z0-9\-_]+)@xxxx.edu', and login seems to be working as expected.
Can it be confirmed whether this is the correct solution? (If there are relevant docs, could I please get a reference.)
If you’re familiar with shells deal with single quotes ' vs double quotes ": yaml parsing seems to follow that same pattern of evaluating what’s inside the double quotes and interpreting single quotes as a constant literal.
Using single quotes, you can us \-, but you need to add a single quote to your single quotes (I don’t think you should use --regex="..." because bash may want to interpret those regex characters, and you’d end up escaping them!).
Or as you’ve indicated, escaping the backslash with another backslash which is perfectly fine if you’re doing this by hand. I think if you have automation, you’d want to sick to single quotes because it’s safer in all languages (because it’s generally treated as literals instead of being evaluated).
I can take this opportunity to update our docs. I’d suggest using single quotes because seeing \\ always confuses me (though I guess I’m ok with 2 or 3 single quotes becuase I see that less frequently?) and for the other reasons I’d mentioned.