Just a quicky for those who are trying to integrate SAML authentication into their app using SimpleSAMLPhp.
Here’s the problem: You’ve set up your client SP, and you’re talking to a remote IdP. You’ve tested your authentication using the SimpleSAML web interface on your SP, but whenever you try it from your app, you hit an exception.
0 /path/to/simplesamlphp-1.13.2/www/module.php:179 (N/A)
Caused by: Exception: The POST data we should restore was lost.
1 /path/to/simplesamlphp-1.13.2/modules/core/www/postredirect.php:38 (require)
0 /path/to/simplesamlphp-1.13.2/www/module.php:134 (N/A)
Assuming no esoteric input filtering, the problem is likely to be in your cookie settings.
If your app creates its own session, it is likely to be creating its own cookie with its own name. E.g.
You must modify your SimpleSAMLPHP config to use the same session name by modifying
config.php and setting
'session.phpsession.cookiename' => 'FooApp' to match.
Simple… but it took me quite a while of being convinced I’d screwed up the server config to track down!
Hope this saves someone some time.
So, following on from the theme of other week’s post, this is a very quick plugin which will opportunistically encrypt email sent by Known.
It works in much the same way as the similar WordPress code; if a key for a user is in the keyring, the email is encrypted before it is sent. It is particularly handy when combined with my PGP Signin code, since that will provide key discovery.
I wrote this for my own use, so it’s not perfect. For example, since Known sends all email as HTML (
unless my plain text email patch is also applied this patch was merged into core), my plugin currently just strips tags, which at least makes the email somewhat readable.
Anyway, kick it around.
» Visit the project on Github...
Just a quick one…. I noticed in my webserver logs, a whole bunch of directory walk “script kiddie” exploit attempts to various wordpress sites on my server, attempting to retrieve my wordpress configuration file:
A directory walk attack is where someone will attempt to use a download feature of some plugin or other in attempt to trick it to retrieve a different file, by passing
../ before the file name. E.g.
None of these exploits was successful, since this is an obvious approach which should be sanitised out of inputs, but part of having a secure system is the concept of strength in depth and every programmer makes mistakes.
So, I knocked together a quick modsecurity rule:
SecRule ARGS "(\.\.\/)+wp-config.php"\
"phase:1,log,deny,status:503,msg:'Attempt to download wp-config.php via the GET line'"
Which seems to shut this one exploit down. HTH 🙂