auth endpoint handling fails with http 401 on Koi

[shark8me]

There seem to be subtle differences in Auth endpoint handling on calling POST on /auth/token between Surfer and Koi. Ideally they should be treated equally.

While getting an Operation from an Meta Endpoint hosted on Koi, Starfish-clj throws a 401 exception, but is successful at getting an Operation from a Surfer hosted meta endpoint.

Using curl, there is no difference in making the request to both servers, and it doesn't offer a clue as to why the requests should fail on Koi-clj.

On Koi:

kiran@kiran-ThinkPad-L460:~/src/ocn/koi-clj$ curl -v -X GET --header 'Accept: application/json' --header 'Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l' 'http://localhost:8191/api/v1/meta/data/14c6a6f272c5dac84db8fd5765c53823fcdc963159e9374a4e46b7716de562aa'
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8191 (#0)
> GET /api/v1/meta/data/14c6a6f272c5dac84db8fd5765c53823fcdc963159e9374a4e46b7716de562aa HTTP/1.1
> Host: localhost:8191
> User-Agent: curl/7.58.0
> Accept: application/json
> Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l
> 
< HTTP/1.1 200 OK
< Date: Thu, 10 Oct 2019 16:13:10 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 575
< Server: Jetty(9.2.21.v20170120)
< 
* Connection #0 to host localhost left intact
{"description":"Run Notebook","license":"CC-BY","name":"Run notebook operation","type":"operation","author":"Notebook Inc","inLanguage":"en","dateCreated":"2019-05-08T08:19:31.521445Z","operation":{"results":{"output-file":{"type":"json","required":true}},"params":{"notebook":{"type":"asset","position":0,"required":true},"input-asset":{"type":"asset","position":1,"required":true},"notebook-name":{"type":"json","position":2,"required":true},"input-asset-name":{"type":"json","position":3,"required":true},"result-asset-name":{"type":"json","position":4,"required":true}}}}

and on Surfer:

kiran@kiran-ThinkPad-L460:~/src/ocn/koi-clj$ curl -v -X GET --header 'Accept: application/json' --header 'Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l' 'http://localhost:8080/api/v1/meta/data/00d14e2a82af328984598babe8f97760312d9b2fce61380a3470d5ce26872448'
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /api/v1/meta/data/00d14e2a82af328984598babe8f97760312d9b2fce61380a3470d5ce26872448 HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.58.0
> Accept: application/json
> Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l
> 
< HTTP/1.1 200 OK
< Content-Type: application/json
< Cache-Control: private, max-age=0, no-cache
< Content-Length: 196
< Server: http-kit
< Date: Thu, 10 Oct 2019 16:25:15 GMT
< 
* Connection #0 to host localhost left intact
{"dateCreated":"2019-05-07T08:56:44.271961Z","size":"7","type":"dataset","contentType":"application\/octet-stream","contentHash":"12cfde9154a545db1ad0c4fe7481342874c5eb0136b770510c3dc573dc0526ec"}

[mikera]

Looks strange. Does Koi use the HTTP basic auth directly or does it issue a token?

Might be work putting in some log statements for the http calls.

[shark8me]

Koi supports both basic and token auth. In Koi's case, this is handled by buddy middleware, and hence is a bit hard to debug using log statements. Surfer doesn't use middleware for this endpoint.

[shark8me]

Wireshark traces show some interesting results on these requests.

Turns out that the Apache HTTPClient

• first sends a POST request to auth/token without an authentication header
• the server should respond with a 401.
• the client then sends a fresh POST request with an auth header
• the server sends a 200 with a valid token.

It turns out that Koi-clj doesn't appreciate a POST to auth/token without an authentication reader, and sends a HTTP 400 (bad request) back.

I'll have to try and modify Koi to not send a 400 bad request. However its not clear why the HTTP Client should send a POST to auth/token without an authentication header.

[AyushVerma2]

@shark8me: code updated and merged the same, kindly review.

[shark8me]

@AyushVerma2 This needs to be fixed in Koi Just to clarify: Koi accepts agents created with auth-tokens. Koi's auth doesn't return a token when passed a username+password, since the Apache HTTP Client first send a request without auth, which Koi rejects as not having authorization.