I learned recently that all GET requests must be safe, idemponent, and cacheable. Imagine if a GET request had some important side-effect, but a proxy cached the result, and returned it without informing the server! Then the side-effect would not occur.
When CAS redirects the authenticated user back to your application, it will append a parameter named ticket to your URL. For instance, the URL you supplied CAS may be called as follows:
Since the CAS auth system redirects the web-browser to an endpoint, the browser will only call GET on that endpoint. This means we need to supply both a GET and a POST endpoint which accomplishes logging in.
Context
idemponent, meaning "the intended effect on the server of making a single request is the same as the effect of making several identical requests". This seems like it isn't the case, since making several requests will start reporting that the GET request failed. However, the internal effect of the system will be the same: logging in 3 times will still result in the user being logged in (or result in a failure 3 times).
However that's a really good point! We should add a comment that says why it's GET, because I didn't realize that GET / POST were enforced strictly until now either!
That's a good point; I'm worried that since the redirect redirects the browser to the login endpoint (so that the backend can authenticate the user given the service token from sfu), the browser will automatically throw a GET request at the endpoint.
Though you're totally right we should expect the same behaviour. I suppose the solution is to redirect to a frontend page which runs some JS to call the backend, but I don't like the idea of zealously relying on js. Something as simple as login should be possible from a browser w/ js off, since some people are going to be logging in as their first interaction with the website...
I learned recently that all GET requests must be safe, idemponent, and cacheable. Imagine if a GET request had some important side-effect, but a proxy cached the result, and returned it without informing the server! Then the side-effect would not occur.
From https://www.sfu.ca/information-systems/services/cas/cas-for-web-applications/
Since the CAS auth system redirects the web-browser to an endpoint, the browser will only call GET on that endpoint. This means we need to supply both a GET and a POST endpoint which accomplishes logging in.
Context