Handling HTTP 302 Moved Temporary redirections

[Cantor, Scott]

On 6/4/14, 5:49 AM, "Marek Denis" <marek.denis at gmail.com> wrote:
>
>Is the redirection an effect, that the user is now authenticated, the
>session is created and the user should now enter the protected URL?

Yes, provided you also send the cookie that was sent after the POST, until
you get a PAOS request back, which is a signal that the session expired
and authentication has to be redone.

>What I found weird was the fact that while I was hitting the URL after
>I got the HTTP 302, the HTTP method didn't matter.

That's up to the resource, it's not part of this profile.

> What mattered was
>whether the request's body was empty or not. I want to confirm if my
>reasoning behing HTTP 302 (why is it happening and why re-sending body
>makes the server fail), since I think HTTP specs accept  resending
>everything to the new location, after HTTP 302.

That's an interesting question, but in practice browsers don't do that.
When you send back a 302 after a form is POSTed, the browser doesn't
replay the form post, it issues a GET to the 302 Location.

I'd have to read the spec to see if that seems off, but that's in practice
what they do, and many SSO systems rely on that behavior.

> And this means I should preserve method request (POST), as well as
>re-send the body to
>the 
>https://openstack4.local/v3/OS-FEDERATION/identity_providers/testshib/prot
>ocols/saml2/auth
>which in that case causes my server behind protected url to fail.

The body is a SAML protocol message so it certainly shouldn't be resent,
but the fact that it fails is really a matter between you and the resource.

-- Scott