Closed aheusingfeld closed 9 years ago
~ $ curl -u user 'https://host/statuses/updates' -v -d 'entry-text=test' >/dev/null
> POST /statuses/updates HTTP/1.1
> Authorization: Basic xxx
> User-Agent: curl/7.37.1
> Host: host
> Accept: */*
> Content-Length: 16
> Content-Type: application/x-www-form-urlencoded
>
} [data not shown]
< HTTP/1.1 302 Found
< Date: Tue, 18 Nov 2014 08:12:22 GMT
* Server Jetty(7.x.y-SNAPSHOT) is not blacklisted
< Server: Jetty(7.x.y-SNAPSHOT)
< Location: /statuses
< Content-Length: 0
< Content-Type: text/plain
< Vary: Accept-Encoding
<
Interesting: How does changing the redirect target fix the post-POST auth prompt?
Was that a rhetorical question? To be honest, it was an assumption on my part (as you typically start with /statuses/updates, log in if necessary, and are prompted again if accessing /statuses on a higher level in the path tree). But I may be wrong, please re-open if that’s the case.
Seems to be fixed! \o/
Was that a rhetorical question?
Nope: I remain genuinely curious what triggered this issue in the first place - but I reckon that's most likely related to our internal infrastructure.
For some reason the redirect after successfully POSTing an entry sends one to aURL which requires the Basic-Auth credentials a second time. Occurs in Safari on iOS 8.1!
Please note: This might be specific to the current environment setup at innoQ