Hi Thijs, On 03/07/2013 04:14 PM, Thijs Kinkhorst wrote: > 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. >
ACK, thanks for the deep explanation. Regards, -- Dario Minnucci <mid...@debian.org> Phone: +34 902884117 | Fax: +34 902024417 | Support: +34 807450000 Key fingerprint = BAA1 7AAF B21D 6567 D457 D67D A82F BB83 F3D5 7033
signature.asc
Description: OpenPGP digital signature
