Op donderdag 7 maart 2013 15:40:31 schreef Dario Minnucci: > > Fixing this would therefore require a bit of reworking of how > > simpleSAMLphp tracks IdP's internally. > > I didn't look at the code enough to provide or propose a definitive and > elegant solution but I guess adding the reason why the IdP was not > considered to the backtrace presented on the browser could help.
So my point is that this is not known at that codepoint so the reason cannot be added. SSP works like this: it reads at one point the set of IdP's configured in saml20-idp-remote.php. At that time already, it will skip any IdP that has expired (and logs a warning). After that, the set of IdP's that's used around the code doesn't include that IdP at all. At the point where this error happens, the entityId is held against SSP's internal list of IdP's, which doesn't contain that IdP because it was already dropped way earlier. So we cannot really change that error because we do not know at that point anything about the IdP. Changing this would be good, but it would require to load all IdP's, keep track of the expired status in the internal data structure, and check at each point where it's used whether it's expired, if so, error out with specific message, if not, continue. Possible, but not a matter of augmenting the error message. -- Thijs Kinkhorst <th...@uvt.nl> – LIS Unix Universiteit van Tilburg – Library and IT Services • Postbus 90153, 5000 LE Bezoekadres > Warandelaan 2 • Tel. 013 466 3035 • G 236 • http://www.uvt.nl
signature.asc
Description: This is a digitally signed message part.
