Stale Request

[Steve Herrera]

Thank you both. I ran SAML-Tracers to catch the output but knowing that the
behavior I was seeing was not a known issue was a huge help. None of the
other SP's links had this issue except this unsolicited SP. That is why I
thought I had misconfigured something. To answer the question, our current
setup uses mostly defaults. For our needs the out-of-the-box configurations
work well for about 90%. It's been great.

So what I found was one of our web headers was the issue. In apache, we had
set our Cache-Control directive. As a test, I removed it and it is working
as expected. I will work on reducing that timeout.

Thanks again for your help. Hopefully this helps someone else who runs into
a similar issue.



On Mon, Nov 2, 2020 at 2:43 PM Ray Bon <rbon at uvic.ca> wrote:

> Steve,
>
> Could it be that the SP cookie is not being removed on logout?
>
> Ray
>
> On Mon, 2020-11-02 at 14:20 -0600, Steve Herrera via users wrote:
>
> Notice: This message was sent from outside the University of Victoria
> email system. Please be cautious with links and sensitive information.
>
> I requested an account with the SP and that just now has been created. It
> is giving me the same errors. Works fine on the initial login, then I
> logout and paste the exact url into my browser and get the same result of
> Stale Request. The parameters in the link are providerID and target.  I've
> tested this with both chrome and firefox with the same result thinking it
> was browser related.
>
>  If I open in a private browser, I login fine, then logout. I open a new
> tab, close the original tab and paste the URL into the URL bar. Also gives
> me a Stale Request.
>
> Steve Herrera
> System Administration
> Information Security
> Bradley University
> Phone: 309 / 677-2336
> FAX: 309 / 677-3460
> Email:  *sherrera at fsmail.bradley.edu <sherrera at fsmail.bradley.edu>*
>
>
> On Mon, Nov 2, 2020 at 2:07 PM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> >    My issue is when the user goes to the unsolicited URL to login, that
> works just fine. But when they log out of the SP and
> > immediately use the unsolicited URL again to try and log back in it
> gives the Stale Request error, similar to hitting the back
> > button.
>
> That's just not what it does, so they can't be hitting that URL again,
> they're accessing something else. With only providerId and/or shire as
> parameters, there's nothing in the link that would or could cause that
> error.
>
> -- Scott
>
>
>
> --
>
> Ray Bon
> Programmer Analyst
> Development Services, University Systems
> 2507218831 | CLE 019 | rbon at uvic.ca
>
> I respectfully acknowledge that my place of work is located within the
> ancestral, traditional and unceded territory of the Songhees, Esquimalt and
> WSÁNEĆ Nations.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20201103/638a58b6/attachment.htm>