Set Cookies in GET request

General Prog (Archived)
1

Is it ok to have a link that is only clicked to redirect the user and set a cookie?

The use case is the following: I’m developping a library for phoenix that allows users to impersonate other users (currently only supports the Coherence authentication system, but can support other systems in the future).

I’d like to have a links that when clicked allow an admin to impersonate a normal user. I’d like to use html anchors (<a> tags) because they are much easier to style, unlike form hacks, which require ninja level CSS skills to turn into a normal link.

I’d like to make it as easy to integrate in people’s apps as possible, so an <a> tag is the best possibility, but that requires setting the cookie in a GET request…

So, is it ok?

1 Like
2

I don’t really see any issue with it.

2 Likes
3

I asked because supoosedly a GET request is something like: give me some data. This action is “set some cookies so that I become someone else”. So from a REST persoective might not be correct. It’s quite pedantic, I know.

1 Like
4

I’m not actually a fan of REST overall, it is very wordy and exposes the schema too directly. >.>

1 Like
5

I’m glad I’m not the only one! I was feeling guilty for not having create, update, delete, etc actions for impersonations in my app: only “impersonate” (self descriptive) and “revert” (go back to being the original user). Those are the only actions I’ll support so I see no need to view an impersonation as a resource I can create, edit, update or delete. In my case I don’t even hit the DB, just set some session keys.

But since REST is all the rage I sometimes feel pressure to conform, especially because I don’t have that much real world experience :smile:

2 Likes
6

FWIW, every web single sign on framework out there does exactly this. If you don’t have the cookie, you get a get redirect that only does one thing, setting a cookie and redirecting you back.

2 Likes
7

I thought you “were supposed to” use POST requests for sign in to keep things “restful”.

1 Like
8

Nope, it’s only post to not expose the password in the query string…

And it has been done that way long before REST was even a thing.

2 Likes
9

Not for ‘restful’, but browsers can pre-grab and cache GET links, but they will not do so to POST links. You should not do anything server-altering in a GET, only POST or so. Setting a cookie does not matter as the browser will not update the cookie unless the GET is actually clicked on.

And yeah, definitely never put a password on a URL, ever ever ever.

1 Like
10

I mean, maybe if you’re a purist. But being pragmatic is probably more useful.

REST is very useful for exposing resources. Like maybe a User’s Posts, or a User’s Profile. That doesn’t mean those things have to follow the schema, but they usually do.

When you have something like a User Session, I don’t think that it’s very useful to be able to discover those things based off a REST User resource.

So people do things like create a Session resource, which is now an industry norm. But I always ask the question, if I don’t need to discover Sessions then why do I always create a resource for it? Ends up the best answer I get is that it fits the management part of REST and most of my application is RESTful, so why not?

I think that in reality you only want to use the “RESTful” ideas in resource management and discovery. If you have special actions that aren’t really either of those ideas then tack them onto a resource or create a special endpoint.

3 Likes