Different base URL for REST API?
Added by Juergen Nickelsen over 10 years ago
Hello all,
first, I could not find any related information in the User's Guide, the FAQs, the HowTos, or the forum — please excuse me if this has already been answered; in that case I'd highly appreciate a pointer to the information.
Can I place Redmine's REST API under a different base URL?
At "/", I already have the Redmine web UI, which is access-controlled using the Shibboleth SSO. (I patched Redmine to accept the REMOTE_USER from the environment as the user name.) As Shibboleth is, in this case, based on a redirect to the login page at the "Identity Provider", and certificates passed around via cookies to avoid entering the password multiply, this is not really a feasible interface for API clients.
Now Shibboleth can also work with Basic Authentication client-side, with the Identity Provider purely as a backend. While this would mean passing the credentials all the time, I think it may work better with API clients. Redmine would still just have to accept the REMOTE_USER name, but to make this work, I would need to configure a different authentication method for this location with Apache, so I would need a different location in the first place.
(I would like to avoid moving the web UI to a different URL (which I know can be configured), as the current one is already published and in use by quite a number of people. Also I'd like to avoid having to use a different vhost name for the REST API.)
At the moment I have (abridged):
<Location /> AuthType Shibboleth ShibRequireSession On ShibRequireAll On require uid ~ .+ RailsEnv production RailsBaseURI / ServerSignature off Allow from all SetEnv GEM_HOME /home/www-adm/.gem-home </Location> <Location /logout> allow from all require valid-user Redirect /logout /Shibboleth.sso/Logout </Location> # Shibboleth error pages <Location /shibboleth-sp> AuthType shibboleth ShibRequireSession Off Require shibboleth </Location>
Now I would imagine, for instance, a <Location /restapi>, for which I would then be able to configure a different authentication method.
Can this be configured with the REST API?
Thanks in advance,
Juergen.
Replies (2)
RE: Different base URL for REST API? - Added by Peter Boguszewski almost 8 years ago
Have you implemented Shibboleth as your authorization method at this point? We are evaluating the effort in getting this to work for us but do not want to put too much time into it (of course). I see that you patched Redmine to allow for REMOTE_USER as the user name - did that ever get in a patch format or even something that could be a plugin? Any information is appreciated!
Thanks,
Pete Boguszewski
RE: Different base URL for REST API? - Added by Juergen Nickelsen almost 8 years ago
Yes, as written above I had already patched Redmine to achieve that. Against Redmine version 3.1.4 (which is what I have currently running) the patch is this:
diff --git a/app/controllers/application_controller.rb b/app/controllers/application_controller.rb
index c1d9f3d..c41243f 100644
--- a/app/controllers/application_controller.rb
+++ b/app/controllers/application_controller.rb
@@ -173,6 +173,8 @@ class ApplicationController < ActionController::Base
start_user_session(user)
end
user
+ elsif (forwarded_user = request.env["REMOTE_USER"]) # web server (e.g. shibboleth) authentication
+ user = (User.active.find_by_login(forwarded_user) rescue nil)
end
end
The comment I wrote originally was:
with a really small change, Redmine uses REMOTE_USER for autologin
Idea taken from http://www.redmine.org/boards/2/topics/39376 , where
Alexey Bykov can do autologin, but not autoprovisioning of user accounts;
I don't care for autoprovisioning and am happy with autologin.
This works not only with Shibboleth, but also with all other webserver-provided forms of authentication that put a REMOTE_USER in the environment, e.g. basic authentication.
I don't know enough about Redmine (nor Ruby in the first place) to know how this could be implemented as a clean solution, plugin or the like, but I'd be happy if someone else did it. (Actually the patch is so small that I think it could perhaps be in the core distribution, with a config switch to enable it. But that, too, would be for someone else to do for the cited reasons.)
Best regards and HTH,
Juergen.