Exception: The POST data we should restore was lost.

[Marcus Povey]

Pulling my hair out on this one...

I'm trying to build an integration between a web app and an auth server using simplesamlphp, and I keep running into this error no matter what I do:

SimpleSAML_Error_Error: UNHANDLEDEXCEPTION
Backtrace:
0 [REDACTED]/simplesamlphp-1.13.2/www/module.php:179 (N/A)
Caused by: Exception: The POST data we should restore was lost.
Backtrace:
1 [REDACTED]/simplesamlphp-1.13.2/modules/core/www/postredirect.php:38 (require)
0 [REDACTED]/simplesamlphp-1.13.2/www/module.php:134 (N/A)

Rather unhelpful :/

The few mentions of this error in the forum are people with the same problem, but no solution.

Any clues what might be going on?

Marcus

[Peter Schober]

* Marcus Povey <mar...@marcus-povey.co.uk> [2016-02-09 12:46]:

> > Caused by: Exception: The POST data we should restore was lost.
> > Backtrace:
> > 1 [REDACTED]/simplesamlphp-1.13.2/modules/core/www/postredirect.php:38

AFAIK this should only be invoked if you set enable.http_post to true,
which isn't the default. Did you try the default (and either properly
fix your website by adding a trusted TLS cert, or living with the
conequences of not having TLS on the SP and each and every subject
logging in getting a security warning from the web browser)?
-peter

[Marcus Povey]

Hmm... I've tried setting enable.http_post to true as well as leaving it as default (false), with no joy.

This is a development environment, so the certs _are_ self signed, but trusted by cURL (if that makes a difference).

Additionally, if I use the simplesamlphp www page on the SP, and run the test login, it is successful, and the correct values from the identity provider is returned.

I'm guessing that points to something related to the specific implementation...?

Marcus

[Peter Schober]

* Marcus Povey <mar...@marcus-povey.co.uk> [2016-02-09 13:20]:

> Hmm... I've tried setting enable.http_post to true as well as leaving it as
> default (false), with no joy.
>
> This is a development environment, so the certs _are_ self signed, but
> trusted by cURL (if that makes a difference).

Whether the TLS cert on the SP web server is trusted or not is not
what I meant: If the SP had no TLS cert at all, i.e., was only
serving plain HTTP (on port 80 or otherwise) then browsers would get a
warning during SSO since a HTTP POST from HTTPS (at the IDP) to plain
HTTP (at the SP) is considered possibly insecure, and so browsers will
produce a warning message. AFAKU preventing that is the sole purpose
of the postredirect.php code.
If you have enable.http_post set the default false and can rule out
caching effects, then I have no explanation off the top of my head as
to why you'd be getting that error from postredirect.php.
-peter

[Marcus Povey]

Aha..... I see what was going on. Looks like at some point someone had installed a WAF on the development machine, which was both undocumented and misconfigured. :/

Gaa!

Thanks for the help :)

[Peter Schober]

* Marcus Povey <mar...@marcus-povey.co.uk> [2016-02-09 15:08]:

> Aha..... I see what was going on. Looks like at some point someone had
> installed a WAF on the development machine, which was both undocumented and
> misconfigured. :/

No idea what that is, but glad you could figure it out.
-peter

[Marcus Povey]

Not quite.... now I've got a separate cause for the same problem.

Seems that while a code integration works in isolation, when you attempt to integrate with something that creates its own sessions, you get the same error.

Trying to track down whether this is some peculiarity of how the app creates a session (there's a bunch of security stuff added that might be triggering sessions to be destroyed), but is there a config setting to get the library to use a pre-initialised session?

Marcus

[Peter Schober]

* Marcus Povey <mar...@marcus-povey.co.uk> [2016-02-09 15:42]:

> Seems that while a code integration works in isolation, when you attempt to
> integrate with something that creates its own sessions, you get the same
> error.
>
> Trying to track down whether this is some peculiarity of how the app
> creates a session (there's a bunch of security stuff added that might be
> triggering sessions to be destroyed), but is there a config setting to get
> the library to use a pre-initialised session?

If you mean that something else is creating and modifying the default
PHP session, them the documentation should cover how to use a
different session store (or configure different settings such as
session / cookie names in config/config.php).
For other interpretations you'd need to add a lot more technical detail.
-peter

[Marcus Povey]

Yep, found it - 'session.phpsession.cookiename' needs to be set to match.

This might be where the other folk were falling down. 

Thanks again for your help!

[rohitjo...@gmail.com]

Hi Marcus,

I am facing similar issue for my configuration.

Could you please explain setting the attribute - 'session.phpsession.cookiename to match with what ? Which value should be given here ?

I am little confused here..

Thanks in advance..!

Rohit