Hi,
Here we never use Apereo CAS /login page success view: we always use
?service=xxx which redirects to the application (CAS protocol)
=> we have no such F5/Ctrl+R issue
NB: we do have back button issue, the solution being
https://www.esup-portail.org/wiki/spaces/CAS/pages/832569350/Am%C3%A9liorer+le+bouton+back+du+navigateur
(french only)
cu
Le 09/06/2026 à 12:22, Adarsh Kuntal a écrit :
Hi Guys,
We are working on customizing the CAS login success flow and have run into a
UX/browser behavior issue related to how the success view is rendered after
authentication.
*CAS Version: 7.3.7 **Current Flow *User submits credentials via POST */login*
Authentication succeeds CAS transitions to a state created via
createGenericLoginSuccessEndState(...) The success view is rendered as a direct response
to the original POST request *Problem *Because the success page is rendered inline as a
response to the POST */login* request, a browser refresh (F5 / Ctrl+R) triggers the
standard "Confirm Form Resubmission" dialog. If the user confirms, the login
flow re-executes — resubmitting credentials and potentially re-initiating authentication
unnecessarily. The root cause is that the browser still considers the current page to be
the result of a POST operation, rather than a GET. *Expected Behavior (Post/Redirect/Get)*
We would like the flow to follow the standard PRG pattern:
User submits POST /login Authentication succeeds CAS issues a redirect to a
separate success URL The browser follows the redirect and loads the success
page via GET Subsequent browser refreshes only repeat the GET — no credential
resubmission, no re-execution of the login flow. *Questions 1. *Is there a
recommended Spring Webflow mechanism within CAS to issue a redirect to GET
request at the end of a successful login, rather than rendering a view inline
to POST request? *2.* Has anyone implemented a custom post-authentication
success page while preserving the PRG pattern? If so, what approach was taken —
a custom end state, a transition action, or something else? *3. *Are there
existing Webflow states or actions in the default CAS login flow that handle
this redirect behavior and could be extended or reused instead of building from
scratch? Any pointers to relevant documentation, flow definitions, or working
examples would be greatly appreciated.
Thank you.
--
- Website: https://apereo.github.io/cas <https://apereo.github.io/cas>
- List Guidelines: https://goo.gl/1VRrw7 <https://goo.gl/1VRrw7>
- Contributions: https://goo.gl/mh7qDG <https://goo.gl/mh7qDG>
---
You received this message because you are subscribed to the Google Groups "CAS
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[email protected] <mailto:[email protected]>.
To view this discussion visit
https://groups.google.com/a/apereo.org/d/msgid/cas-user/add8ad00-fece-47bc-8817-6cedb7192ac7n%40apereo.org
<https://groups.google.com/a/apereo.org/d/msgid/cas-user/add8ad00-fece-47bc-8817-6cedb7192ac7n%40apereo.org?utm_medium=email&utm_source=footer>.
--
Pascal Rigaux
Expert en développement et déploiement d'applications
DSIUN-SAS (Service applications et services numériques)
Université Paris 1 Panthéon-Sorbonne - Centre Pierre Mendès France (PMF)
Coordonnées : https://annuaire.univ-paris1.fr/Pascal.Rigaux@
--
- Website: https://apereo.github.io/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/apereo.org/d/msgid/cas-user/f72c918e-8653-4c6e-8197-39f46d71337c%40univ-paris1.fr.
