Suggestion on how to constraint the application by a GET parameter

[fluca1978]

I don't like the idea very much, but there is the need to land into my application from different locations, i.e., from different links.
Depending on the soucre link, I need to constraint the application somehow.
My idea is to place in the source link a parameter, something like https://foo.com/index?from=departmentA so that I can recognize the from incoming link and store the departmentA value in the stash.
From then, the stash will provide me the discriminatory value (departmentA) to constraint my application.

Is this a good idea or is there something better I cannot come up with?

[kraih]

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer

[fluca1978]

@kraih thanks for pointing me to the referrer, but I'm not sure I got it.
The need is: if the user lands from a set of specific locations, do behavior A, otherwise do B.
Using the referrer I had to list all the locations that would trigger A and compare, is it correct?

[guest20]

If the people linking to your site already have to add ?from=A why not have them link directly to the action for the thing you want them to do?

It depends a lot on what the value is... It's going to be different if it's an access token, an affiliate id, or just a survey id.

[fluca1978]

If the people linking to your site already have to add ?from=A why not have them link directly to the action for the thing you want them to do?

I have an unified action, that has to constraint some data, e.g., some menu fields, to narrow the choices depending from where the users are incoming.
One idea could be to set an URL so that if invoked with extra arguments, e.g., /action/A insrtead of /action will detect the incoming part. Is this what you meant?

It depends a lot on what the value is... It's going to be different if it's an access token, an affiliate id, or just a survey id.

All the incoming traffic is coming from the very same domain, it just depends on which page the link is placed.

[ghandmann]

All the incoming traffic is coming from the very same domain, it just depends on which page the link is placed.

Well in this case the Referer Header may be exactly what you would like to use.

If the user is on the Page http://some.domain.com/some/page.html and clicks a link to your app to http://your.app.com/some/api/endpoint/ the HTTP referer header would be set to http://some.domain.com/some/page.html. And if the user is on the page with the URL http://some.domain.com/some/other/page.html and clicks a link to the same endpoint of your app, the HTTP referer header would be set to http://some.domain.com/some/other/page.html.

So based on this header value, you could decide what to do in your endpoint.

Only issue with HTTP referer header: Some browsers/Users will not set the Referer at all since it emposes a privacy risk (the site you are visiting knowns from which site you are coming).

[fluca1978]

Only issue with HTTP referer header: Some browsers/Users will not set the Referer at all since it emposes a privacy risk (the site you are visiting knowns from which site you are coming).

It would be grat, but I'm experiencing exactly this: refer is undef, so it means it is not (always) passed and hence is not so reliable.

[ghandmann]

Than you are left with URLs that contain some unique identifier (Query params or URL params or unique URLs). But even these impose a small risk: A user that knows that these URLs contain something unique is always able to alter the URL before visiting it.

So in any case you need to handle that scenario somehow. And you are not able to strictly restrict that a user from Department A is not using the URL the should only be used by a user from Department B. Since URLs are no real secret. They can be shared, inspected, etc.