#6242 make it possible to host a custom webservice behind basic authentication
Originally created by: emera
When making a request with an authorization header to a webservice (in extension tool), a redirect is issued to the allura login page regardless of the correctness of the credentials.
To make it possible to host a webservice behind basic authentication, we propose a solution similar to the one for Ticket [#4370] :
diff --git a/Allura/allura/lib/custom_middleware.py b/Allura/allura/lib/custom_middleware.py
index 6c121b4..5b2d4e9 100644
--- a/Allura/allura/lib/custom_middleware.py
+++ b/Allura/allura/lib/custom_middleware.py
@@ -94,7 +94,9 @@ def __call__(self, environ, start_response):
status, headers, app_iter, exc_info = call_wsgi_application(
self.app, environ, catch_exc_info=True)
is_api_request = environ.get('PATH_INFO', '').startswith('/rest/')
- if status[:3] == '401' and not is_api_request:
+ is_service_request = '/service-' in environ.get('PATH_INFO', '')
+ do_not_show_login = is_api_request or is_service_request
+ if status[:3] == '401' and not do_not_show_login:
login_url = tg.config.get('auth.login_url', '/auth/')
if environ['REQUEST_METHOD'] == 'GET':
return_to = environ['PATH_INFO']
According to the above code, a redirect to the allura login page is not done if
the mount label of our custom Allura tool starts with "service-".
Originally by: emera
the patch
Hi there. Thanks for the patch. I think checking for '/service-' in the URL is a bit too broad of a check, though. Somebody could create a wiki tool, for example, at /p/myproject/service-docs or something like that, and that would have this special logic applied. I think a more specific flag of some sort should be used. Are you raising the 401/Unauthorized from within your tool? Or does it come from within allura (e.g. the standard security system). I'm thinking maybe if it comes from your code, then it'd be possible to set a flag on the exception object, or the response or something like that.
Another option might be to make the '/service-' value a configurable option so you can set that in your .ini file and other deployments of Allura can set a different value, or none at all.
Originally by: jan_blok
Hi Dave, I think you are missing the point for this patch.
The Allura dev's did exclude /rest/ path for the Allura rest service
Any other tool builder which also don't want to be bothered with login screen result for a basic-auth call towards its tool, is facing the same problem as as you did while building rest service.
This patch suggests a generic approach to exclude login screen result for any rest call towards a rest service provided by a tool.
I fail to see how a flag could make a difference here...would it be an idea to change the suggested "/service-" to "/rest-" ?
Thanks for you consideration!
Hi Jan. The difference is that the /rest/ check will only match if the URL path begins with /rest/ and not anywhere else in the URL. So for example, /rest/p/allura/tickets/6242/ (the API endpoint for this ticket) is excluded but /p/myproject/rest/foo is not (which is correct; that could be a regular wiki page or something else that shouldn't get special handling). The /rest/ prefix is part of the Allura core and maps to the "api_root" controller specified by each tool.
Perhaps using the "api_root" controller and /rest/... URLs would work well for your tool. I think that'd be a good option to explore if you haven't already.
If that doesn't work for your tool, I think making using a flag on the exception (not sure exactly how well that would work out) or making the "/service-" string be a configurable pattern (probably easier) would ensure that no regular tools could accidentally be handled differently because of the project or tool name in the URL. If it was a configurable pattern, Allura instances that don't need it wouldn't have to set it, and would avoid any risk of incorrect matching).
Hope that makes sense
Originally by: emera
Works with "api_root" controller and /rest/* url.
Thanks.
Great, glad that worked for you!