In a nutshell, I'm trying to figure out how to programmatically enable and disable the redirection for mobile phones, based on a session value, on a per request basis (not statically for everyone).
Here's the back story:
I'm currently using 51Degrees in my ASP.NET application to redirect requests to the mobile version of the site. I would like to add a feature where users can enable and disable this redirection from a "Settings" page. The setting will be different for each user, and so far every setting I've found to disable 51Degrees is static. This makes it difficult to disable it for a subset of users.
One semi-solution I had was to set firstRequestOnly="true" and reverse the redirect if it wasn't supposed to happen. Although firstRequestOnly="true" has caused a number of other headaches (unrelated) so I would like to keep it at firstRequestOnly="false" and simply enable/disable the redirection based on a session value per request, or per user. The problem is that I can't figure out a clean way to do this.
Set the cookie in the page prerender event based on the setting your user has choosen in their profile. You would need to have firstRequestOnly set to true. If the user does not want redirection it should have a very long expiry time, if they do then set a short expiry time.
I ended up just downloading the source code and adding in an option to opt-out of the redirect if a certain session field was present and set to true. This allowed me to set that session value from my code depending on what the user had setup in the settings section. Not the best solution since it's going to be more difficult to upgrade 51Degrees down the road, but it works.
Related
One of my clients has a cross domain analytics set up.
Everything works well, but there are different behaviors when user gives full cookie consent and when he allows only strictly necessary cookies.
Behavior in case of full cookie consent:
GA stores data into cookies i.e. _ga cookie _ga_ID can be found in console cookie tab.
Behavior in case of only strictly necessary cookie consent:
GA stores some data in URL, for example:
https://www.example-page.com/?_gl=1*XXXXXXX*_up*MQ..*_ga*ZZZZZZZ.*_ga_YYYYYYY*YYYYYYY..
According to google documentation the second case is default behavior. And cross domain measurement is working when _gl param is added to url.
What I do not understand is why are URL params not added everytime and only when some cookies are not accepted, so I would like to get better understanding of this.
There is also a possible issue which I do not understand and that is:
GA params are added to url also when user is just switching between subsites in the same domain i.e. from www.example-page.com/home-page to www.example-page.com/about-page. If I understand correctly this should not happen as I am staying within domain.
The questions I am most interested in are:
How is GA determining if it should store its data as cookies or push it to url?
Where are these parameters stored before user redirect first time? Is it part of datalayer / google_tag_manager global variables?
Is there way to store the params somewhere else than in url when full cookie consent is not granted?
Is adding of GA params to url even when staying withing same domain a correct behavior?
Project details:
Site is running on Wordpress and use OneTrust for cookie management.
EDIT: Issue with URL resolved.
In my case this issue was caused by update of consent mode template (gtm-templates-simo-ahava). Reverting to previous version fixed the problem. Possible cause of the problem can be maybe connected to this pull request in template repository
How is GA determining if it should store its data as cookies or push it to url?
Pushing the data to url is the mechanism of cross-domain tracking. You set a list of domains that cross-domain tracking should work for. This is likely your problem here. You're not supposed to set subdomains, only TLDs in vast majority of cases.
Where are these parameters stored before user redirect first time? Is it part of datalayer / google_tag_manager global variables?
This data is stored in cookies before the user goes to a different domain. If cookies are deleted, then it's stored in the JS scope of the GA library. This implies that they would be erased and regenerated on JS context loss. Loss on a page unload, regeneration on a page load.
Is there way to store the params somewhere else than in url when full cookie consent is not granted?
Well. Yes. But very tricky and expensive. And the immediate question is why would you do that. This would defeat the purpose of blocking the cookie. Natively, GA doesn't support other methods of passing the value, but if you're into tinkering, you can either store the value on your backend and then retrieve it, using some "primary functionality" cookie. Another option is using third party server's cookies, but that would defeat the purpose even more.
Is adding of GA params to url even when staying withing same domain a correct behavior?
No, it's most likely a mistake.
Now, you really asked all the right questions, so I don't have much to add, except that disabling your primary anonymized behavioral tracking is usually a lazy "safe" choice. And lazy here implies wrong.
Normally, larger corps don't block primary tracking. They only block third party marketing-related tracking. Basically, pixels. They consider their main analytics part of the primary functionality, which is a strong case given that main analytics data is often used in debugging, performance measurement and even for app security audits.
Finally, using onetrust or a similar solution to completely manage your tracking is sub optimal. They basically just destroy all "offending" cookies all the time. This will mess up your behavioral data very significantly.
The proper way to use consent management systems is declaring user consent choice in your tag management system and then in it, block rules/tags from firing in case the consent is not given. You normally just carefully block marketing tags there based on consent. Remember, consent management systems are only deleting cookies. Because that's trivial. They don't block network requests. Absence of cookies may not prevent the data from being sent, often even uniquely identifying the client, using the primary cookie's user id, allowing to match the activity to the backend database.
I have built an ASP.Net MVC site using Forms Authentication for a client.
Recently, they have requested that an authenticated user be restricted to a single browser session. That is, if the user raises a new browser instance, or opens a new tab on the original browser window, that he/she be logged out of the original. They insist on the added security.
Does anyone know how I might approach this? Thanks in advance.
Personally, I would push back and ask exactly what security this is bringing. Maintaining state like this counter to web architecture and is only going to bring you and your users grief.
Here is what I would do if presented with this problem:
Store the username of the user in your database (i.e. LoggedOn table).
When a user logs on, check to see if their username is already present in the LoggedOn table.
If the user isn't already logged on, insert a row into the table with the username and the current time; otherwise present the user with a message informing them that they can only log into the system from one device at a time.
Include logic to expire and delete the rows in the table if a user's session expires or if the user logs out.
First a disclaimer: I'm no expert in web programming.
Perhaps you might try a system where every user interaction requires the submission of a random value that's been generated for that page (much like what's used for CSRF protection.) That key could be kept under the user's session information on the server, and if a page is ever requested without the correct key as a URL parameter, the session is invalidated. The URL from one browser won't work in another, either, since once a URL is gone to, the user's session key has changed. The only way for a user to transfer a session between tabs would be to copy the URL of an unclicked link and paste it in a new tab's address bar. Switching browsers would be even more complex assuming that ASP.Net uses a session cookie: the user would have to transfer the cookie from one browser to another. Going back would also fail, as all the links on the previous page, and the URL for the page, would carry an incorrect session key.
Also, for reference, I believe the US Gov't TreasuryDirect site works in the way you've described, though I've never looked at how they manage it.
Thanks, people for the suggestions. Each had strong merits, however I had to take a hybrid approach. I found an incredibly simple suggestion from this post.
I implemented table of active users as Karl suggested as well. This will give the client the ability of deactivating the user on demand.
Thanks again.
Think of it as one active view at a time instead of one browser or tab. Or convince the customer to view it this way.
You can always issue a unique cookie for the browser session (ASP.NET Session) and allow communication to the latest cookie issued effectively making only one session active at a time, and therefore rendering other open sessions (browsers, tabs, etc) useless with the app by disallowing them communication any longer or serving up an error page for them. To do so you have to recognize who the user is and authenticate them against your app. This is half the puzzle and will force the user down to use your app in only a single browser at a time on their machine.
The other part of the problem is to pare down the windows and tabs that are part of the same browsing session of that browser, to allow only one view to be active at a time. To do so you can issue a unique sequential ID to the viewstate of each page for postback to the server to uniquely identify that page apart from other pages sharing the same session state (whether that page be in a browser tab, a frame or new window, etc). Or a code of your choice that's traceable. You then know which page is posting back within the session and can disallow others or deactivate previous ones by, again, shutdown down communication in some manner or serving up an error page, etc.
A new browser instance or a new tab may or may not be part of the same browsing session depending on how the browser is configured. I believe, for example, IE provides a setting that allows the behaviour to be set of whether a tab opens in a new process or session or shares the session. You won't necessarily get expected consistency across browsers to rely on for this feature, therefore you need to take programming steps to reign it in, like those described above.
You can additional steps like disallowing the user to be connected from a different IP# at the same time.
I have created a web page but i want to restrict only one instance of the page should be running at all times. The scenarios are given as below.
First time - User launches the page by URL and page loads.
User types URL again in another window and it should say that a page is already open OR refresh the existing page.
User closes the window and tries again - new fresh page will be loaded.
Additional Details : I have a database, user authentication.
Tried So Far : Set a flag in DB-->> This method how do i redirect the user back to the page which is already opened.
Any ideas to implement this.?
Thanks in Advance for your opinions and suggestions.
Perhaps you should use a cookie which expires when the user closes the browser. However, all browser instances may need to be closed.
First time, there is no cookie and http_referer does not contain the same domain. (set cookie now)
http_referer contains the same domain
cookie expires and go back to (1)
You should consider using cookies for this. Create a session-long cookie upon opening of the window and destroy it upon closing of the window. If a cookie already exists, you know the window is already open.
This of course relies on javascript and is easily got round. You can not use a server-side solution because it would be impossible to catch the closing of the browser window in order to clear the cookie.
Personally, I wouldn't try and restrict the opening of multiple windows but restrict the functionality available in each window. This approach would be much easier to control using a server-side approach, e.g. events fired in the window can be validated server-side.
I have a several site collections in the same web application and I need to handle events when user goes from one site collection to another. I need it for specific actions, like setting "lcid" cookie for changing default language of site and claims values to user properties mapping.
Currently I'm using custom HTTP module, which handles all PostAuthorize web application requests and checks current user and site collection, holds last visited site for each user in collection and fires a custom event for subscribers, when detects transition between site collections.
But I think this approach slows down performance of web application. And from logs I see that there are to many PostAuthorize requests even when user simply clicks a link to page in other site collection. Also, in similar cases sometimes there is a series of requests to "next" site collection, then to "previous", and then again to "next". Also there are some issues with SharePoint Designer (can't edit page) become when this module is active.
Could you give me a advice with better approaches for this task? Thanks in advance.
1 way is using a hidden control and cookie.
Keep a hidden control in all the masterpage of all the targeted sitecollections.
This control will check the current site collection url and save it in a cookie. Possibly in the same cookie where you are storing lcid.
From next load onwards it will try and match the url in the cookie and the current site collection url. If different call the code you want to execute and update the url in the cookie.
This will be much lighter on performance than an httpmodule.
I have a ASP.NET website where after a specific user action, I have to issue a new AUTH cookie almost identical to the one the user already currently has. I'm having trouble finding out whether the current AUTH cookie is supposed to be persisted or not. Any ideas on how to do this?
If the cookie expiration isn't set, then it's session.
If you are trying to discover it's life via the browser, you can use firebug with the firecookie plugin. Or the web developer tool will also enumerate all the cookies on a page.
Any cookie that is not session will have Expires field. If you send it into feature date - you will get it "permanent" until the time expires. If you want to maintain "permanent" cookie status you would refresh it on next user login and shift it further into the future. One month is usually enough