application override not working on some clients

[Cantor, Scott]

> Thanks Scott, this is very helpful. Our Shibboleth2.xml had been on an IIS
> machine before my time and so I think that's why we had path statements in
> the RequestMap element. I've now commented out the RequestMap
> section, removed the .htaccess file and have created <Location> blocks in the
> apache config as such:
> <Location /path/to/secure/resource>
>         ShibRequestSetting applicationId default

Don't do that. Firstly, default is always the default, so you never need to specify it. But in addition, you cannot just override paths like that, because that will break it. If that's a true override, and you're overriding the whole vhost, then you MUST apply that setting to the whole vhost, otherwise the requests to /Shibboleth.sso will not override, and you'll loop.

But everybody will loop, not just somebody's phone.

> <Location /path/to/secure/resource>
>         ShibRequestSetting applicationId <vhostappid>

Right, so that will break it. The settng there has to be applied to Location /

> Everything is working as it had before but I still find it the second
> <vhostappid> item hanging on my android phone so I presume that will be
> the case for the others that encountered this problem.

As defined there, it should loop for everybody. The POST back to /Shibboleth.sso/SAML2/POST will bind to the default application, and then the request to the original resource will not have a session valid for that applicationId, and it will loop back to the IdP, and then rinse and repeat.

That said, make sure it's a loop by checking the logs and who should see many sessions created in the transaction.log for your address in a short timespan.

If it's not a loop, then you need to figure out what URL it's actually requesting, because that URL must be hung or not connecting.

-- Scott