You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Great we have a "token". Let's see what that does:
POST http://kibble.localhost/api/org/list HTTP/1.1
Authorization: token abdb02d7-6450-4af2-9ef3-add42907e09c
Content-Type: application/json
HTTP/1.1 403 Authentication failed
Date: Wed, 27 May 2020 17:29:05 GMT
Server: gunicorn/20.0.4
Content-Type: application/json
Connection: close
Transfer-Encoding: chunked
{
"code": 403,
"reason": "You must be logged in to use this API endpoint!"
}
Hmm, nothing. Let's attempt traditional authorization schemes. Note that my REST client automatically Base64 encodes 'user pass'.
POST http://kibble.localhost/api/org/list HTTP/1.1
Authorization: Basic [email protected] blah-blah-blah
Content-Type: application/json
and
POST http://kibble.localhost/api/org/list HTTP/1.1
Authorization: Digest [email protected] blah-blah-blah
Content-Type: application/json
both result in:
HTTP/1.1 403 Authentication failed
Date: Wed, 27 May 2020 17:32:52 GMT
Server: gunicorn/20.0.4
Content-Type: application/json
Connection: close
Transfer-Encoding: chunked
{
"code": 403,
"reason": "You must be logged in to use this API endpoint!"
}
Hmm. Let's fiddle with kibble_uisession and see where that leads.
Conclusion: I have failed to refute the initial theory. Can anyone refute this and if not, comment on any plans available to provide proper authorization scheme for REST Clients?
The text was updated successfully, but these errors were encountered:
Theory:
Apache Kibble only supports cookie authorization for its REST API.
Attempt(s) to falsify the above:
Great we have a "token". Let's see what that does:
Hmm, nothing. Let's attempt traditional authorization schemes. Note that my REST client automatically Base64 encodes 'user pass'.
and
both result in:
Hmm. Let's fiddle with kibble_uisession and see where that leads.
Oh, hello! Let's see what gives.
Conclusion: I have failed to refute the initial theory. Can anyone refute this and if not, comment on any plans available to provide proper authorization scheme for REST Clients?
The text was updated successfully, but these errors were encountered: