[
https://issues.apache.org/jira/browse/NIFIREG-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16299077#comment-16299077
]
ASF GitHub Bot commented on NIFIREG-74:
---------------------------------------
GitHub user kevdoran opened a pull request:
https://github.com/apache/nifi-registry/pull/63
NIFIREG-74 Change login to use HTTP Basic Auth
Changes the REST API /access/token/login endpoint to use HTTP Basic Auth
for reading username and password.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kevdoran/nifi-registry NIFIREG-74
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi-registry/pull/63.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #63
----
commit 5ea5f70427d256a4e571cc3e3ec4904472f57ec5
Author: Kevin Doran <kdoran.apache@...>
Date: 2017-12-20T20:20:18Z
NIFIREG-74 Change login to use HTTP Basic Auth
Changes the REST API /access/token/login endpoint to use HTTP Basic
Auth for reading username and password.
----
> Change the REST API login endpoint to use HTTP Basic Auth
> ---------------------------------------------------------
>
> Key: NIFIREG-74
> URL: https://issues.apache.org/jira/browse/NIFIREG-74
> Project: NiFi Registry
> Issue Type: Improvement
> Reporter: Kevin Doran
> Assignee: Kevin Doran
> Fix For: 0.0.1
>
>
> Currently, the REST API endpoint for logging in using a username & password
> (with a configured identity provider) is a POST that accepts Content-Type
> application/x-www-form-urlencoded, with form parameters in the body.
> Specifically, requests should be formed as:
> {noformat}
> POST /nifi-registry-api/access/token/login HTTP/1.1
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 32
> username=nobel&password=password
> {noformat}
> However, the Jersey resource we are using for the REST API in the server will
> also respond to username and password passed in URL parameters, eg:
> {noformat}
> POST /nifi-registry-api/access/token/login?username=nobel&password=password
> HTTP/1.1
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 0
> {noformat}
> This is incorrect, but it will work (actually, the current implementation of
> the javascript client is logging in this way). As there does not appear to be
> an easy way to prevent the server from mapping url parameters to form
> parameters, a client could mistakenly send url parameters to the server and
> get a token back. The issue is that the URL is not generally considered a
> protected element of the request, even when using a secure connection, so
> libraries might log the full URL with parameters, thus leaking client
> credentials. For example:
> {noformat}
> DEBUG o.s.security.web.FilterChainProxy
> /access/token/login?username=nobel&password=password has an empty filter list
> WARN o.glassfish.jersey.servlet.WebComponent A servlet request to the URI
> https://localhost:8443/nifi-registry-api/access/token/login?username=nobel&password=password
> contains form parameters in the request body but the request body has been
> consumed by the servlet or a servlet filter accessing the request parameters.
> Only resource methods using @FormParam will work as expected. Resource
> methods consuming the request body by other means will not work as expected.
> {noformat}
> After looking into options, the best approach for now seems to be to migrate
> the login endpoint and the JS client to use HTTP Basic Auth instead of form
> encoded parameters. This will prevent a client from inadvertently sending
> form params in the URL to the server in the HTTP POST.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
