Need preauth provider to use with local database accounts provider
Closed this issue · 9 comments
For consistency in the REST API, we should have a preauth provider that just returns a login form and/or form-building instructions for use with the local accounts provider.
I think this would be a solution to #6 i.e. all configs have a fallback preauthn provider rather than an absent mechanism.
See https://github.com/informatics-isi-edu/webauthn/blob/globus_auth/doc/rest_api.md for provider-independent login/logout support
With an existing deployment w/o a preauth provider enabled in the config, a GET /ermrest/authn/preauth responds 200 OK, application/json, and JSON value of null... is this really appropriate? I would expect some other error status like 404 Not Found or 405 No Method in the case that no preauth provider is configured.
The message Add an option to the db provider to present a pre-written html form. on 9065c67 leads me to expect a text/html response. However, what I get is:
HTTP/1.1 200 OK
Date: Tue, 29 Mar 2016 17:06:30 GMT
Server: Apache/2.4.18 (Fedora) OpenSSL/1.0.2g-fips mod_wsgi/4.4.8 Python/2.7.10
Content-Length: 203
Content-Type: application/json
{"authentication_type": "database", "login_form": {"action": "/ermrest/authn/session", "input_fields": [{"type": "text", "name": "username"}, {"type": "password", "name": "password"}], "method": "POST"}}
This happens regardless of whether I send an Accept: text/html header. The presence of the authentication_type and login_form outer object fields makes me think some server-side transforms are incomplete here...?
It always returns a JSON object. The idea is that the application sends GET /preauth and looks at the results. If there's a redirect_url, the application redirects the client to that URL (which might point to a static html form on the local host); otherwise, if there's a login_form, the application constructs an html form based on the contents of the login_form structure.
If we have no idea what to do, we shouldn't have a provider, and I'm going to make it return 405 in that case.
Although I guess that doesn't handle the case of a badly-configured provider.
confirmed that database preauth provider works as described