You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some clusters are set up in a way that there are valid users who can authenticate to Apache (via OpenID Connect, or however) but do not exist locally in a way that the Nginx PUN staging tool can then run as that user. For instance, our site uses an OIDC provider which will authenticate any user in our organization, but our cluster requires separate creation of local user accounts, it doesn't use our directory as a source of actual users, only for authentication of users that do exist.
The effect is that mod_ood_proxy sees a properly-authenticated request and attempts to start up a PUN for this user. The nginx_stage command will fail (because the user doesn't exist locally) and the output of the CLI tool gets captured. The Lua module then returns a 404 error with the response content being the output of the stage command. This is not particularly helpful for users in this scenario, which for us are potential cluster users.
If this response could be replaced or redirected to a default page that explains that the local user doesn't exist, particularly if this page could be customized in the style of the missing home directory page, this would allow us to present a page for these potential users who tried to use the system without an actual account which could direct them to our account creation process.
I can imagine ways to do this by modifying the Lua module to instead set the response filename to a (configurable) error page, but unlike pretty much all of the existing content, this would need to be served directly by Apache instead of by the PUN, perhaps analogously to public/need_auth.html. I could imagine other ways to do this with Apache config directives though, and I don't know the impact of different types of changes on maintenance.
The text was updated successfully, but these errors were encountered:
Another thought on handling this: you wouldn't necessarily want to just always return an error page with that specific of content, there are different reasons that the PUN stage command can fail and if unless you redirect to a catchall page you might end up misleading both users and admins. Reliably presenting the right error might involve parsing the stage command output or possibly tweaking its error output to be more easily parsed.
As discussed at office hours:
Some clusters are set up in a way that there are valid users who can authenticate to Apache (via OpenID Connect, or however) but do not exist locally in a way that the Nginx PUN staging tool can then run as that user. For instance, our site uses an OIDC provider which will authenticate any user in our organization, but our cluster requires separate creation of local user accounts, it doesn't use our directory as a source of actual users, only for authentication of users that do exist.
The effect is that mod_ood_proxy sees a properly-authenticated request and attempts to start up a PUN for this user. The
nginx_stage
command will fail (because the user doesn't exist locally) and the output of the CLI tool gets captured. The Lua module then returns a 404 error with the response content being the output of the stage command. This is not particularly helpful for users in this scenario, which for us are potential cluster users.If this response could be replaced or redirected to a default page that explains that the local user doesn't exist, particularly if this page could be customized in the style of the missing home directory page, this would allow us to present a page for these potential users who tried to use the system without an actual account which could direct them to our account creation process.
I can imagine ways to do this by modifying the Lua module to instead set the response filename to a (configurable) error page, but unlike pretty much all of the existing content, this would need to be served directly by Apache instead of by the PUN, perhaps analogously to
public/need_auth.html
. I could imagine other ways to do this with Apache config directives though, and I don't know the impact of different types of changes on maintenance.The text was updated successfully, but these errors were encountered: