If I have a small microsite and on the first page I want to ensure that the user cannot jump to a non secure page between (e.g. 2 or 3), what would be the best way to implement this? The next page can only be seen if the user sets a certain item in a drop down box.
My first thought is cookies. If the user goes to the second page and the cookie's value is null, then there is a redirect to a failure page. If the user chooses the right value, the cookie's value is set to being a success. Would this approach work if I send a link on the 2nd page to a friend on another PC?
Is there a better way?
Cheap, downa and dirty? The cookie or session value work. Neither are reliable long term.
If you are making it so a user can only see certain info after selecting a drop down, you can hide it in a panel and only show that panel when the drop down is selected. This is the most useful if you do not mind the user having to select from drop down each time. You can use this with a cookie, as well, if you want the user to be able to see the data without selecting the drop down.
Hidden in the same page (drop down in one panel, info in another), you can keep it hidden perpetually.
If this has to be a second page, you can also put the page in another directory, and then put a web.config file in there that requires log in. You can then make it like a "log in" by "logging in" every person that answers. You end up using the Membership bits, but they are not hooked up to anything.
Cookies are not a good idea for this for one specific reason. They are under the control of the user, not you.
If a user has cookies disabled (globally or just for your site), they won't be able to get to page 2 now matter how many times they've read page 1.
In addition, if they know what your cookie contains (i.e., it's not encrypted), they can easily create it themselves or forward the method to a friend to get them to create it.
Regarding your question on whether you could send the page 2 link to someone else, cookies belong to the computer. That means the "someone else" would almost certainly not have the correct cookie for properly viewing page 2: they'd get an error.
We implemented a similar scheme (many years ago so there may be better ways to do it now). It involved storing a special "one-time" key when delivering page 1 to an IP address. The links in that page 1 were modified to include this key as an argument so that, when you requested page 2, the key was sent through as well.
The keys had a 30-minute lifetime (configurable but we ended up at 30 minutes). In order for us to deliver a page 2, the request had to come from the same IP address and have the proper key.
This prevented forwarding of links to other places and ensured the links had limited lifetimes.
Whether that's a viable solution for you is a question only you can answer. I know we got a few complaints from people who bought up page 1, then went out for a coffee. When they got back, their attempt to access page 2 was unsuccessful. We fixed this by simply redirecting them to page 1 with a suitable error message that their key had timed out.
Not perfect but, since the users were educated as to why it was happening, they understood its necessity.
If I understand your question correctly then the link you send to your friend will not work as they will not have the cookie stored in their browser memory or on their machine. This would also be true if you stored the value in Session as they will be creating their own new session when they opened the link.
To get this kind of behaviour when sharing links you will need to pass the value in a querystring i.e. when you select the desired option on page 1 and sublit the form the postback takes the selected option and then redirects to page 2 with option appended to the url as a querystring value.
Related
Do anybody knows, how I can get all logged in users in TYPO3 8.7 with extbase? Shure, I can get the fe_users sessions, but isnt there an more extbase like way?
UPDATE:
I need to get the uid's of all currently logged in users. It seems
that the is_online field holds only the timestamp from the last login.
If the user is logged out, this filed has still the timestamp. maybe
is reading the fe_sessions really the better way?
You can evalute two fields every fe_users record holds: is_online and lastlogin.
The field lastlogin is refreshed on each server access.
AFAIK the field is_online is evaluated in the form now - lastlogin > n.
So in general you have another problem, as you can not clearly detect which users are active. You only have the information when a user last time contacted the server.
The interval n is necessary as an user has no continous connection to the server. He can just read some text before he clicks to another page, but he also could close the browser window every time. And even then, if the session cookie is stored, he might use the website again and can be online immediately. Was he online the whole time?
On contrast to this a user is not even marked offline (is_online = 0) if he does an explicit logout.
Say I have two pages on a site called “Page 1” and “Page 10”. I'd like to be able to see the paths visitors take to get from “Page 1” to “Page 10” with full URLs intact. Many of the URLs (including those for “Page 1” and “Page 10”) will include query strings that are important.
Is this possible? If so, how?
Try using behavior flow reports. The report basically shows you how visitors click through your website. There are a lot of ways to customize the report, with which you will need to play around to really answer your question. By default, the behavior flow focuses on entry and exit points of visitors, regardless how many times they hit the different subpages in between. However, I'm sure you can set appropriate filters and settings to answer your question.
I use two methods for tracking where people have been on my website:
Track and store the information in my own SQL database. (details below)
Lead Forensics (paid subscription, but you can do a trial).
For tracking and storing my own data, I record unique visitors based upon the IP Address they're connecting from and then have a separate table that records all page views that links back to the unique visitor table.
Lead Forensics data simply allows me to link up those unique visitors with actual companies that have viewed my website.
Doing it yourself means you don't have to rely on Google working for your records to work, and in my experience Google Analytics tends to round numbers so you don't get a true indication of numbers, and also you can remove bots and website trawlers from your data by tracking the user agent string.
As a somewhat ugly hack you could use transaction tracking. If you use the same transaction id multiple times subsequent products will be added to the existing data. So assign an ID at the start of the visits and on each page record a transaction with the current page url as product name (and the ID as transaction id). This will give you the complete path per user (I am frankly not to sure how this is useful - at some point you probably want aggregated data. Plus each transaction and product counts towards your quota for interaction counts, so on a large site you might run over the 10mio hits limit).
you can do it programatically
have a MAP in the backend which stores the userId (assuming u would have given a unique ID at the time of login to each user) with a list of Strings(each string being URL visited by that user)
whenever the user hits another URL from Page 1(and only from page1, check it using JS), send a POST request to backend with the new URL in its data section.
In the backend, check if the URL is of Page 10 and if not, add this URL as a string into the MAP for that corresponding user
Finally, when the user clicks on the Page 10 URL, you know the URLs in the way from Page 1 to Page 10 and so use them.
Though if I consider JS and I have not misunderstood your question, we can get the previous URL from request header information using document.referrer.
Are you trying to do it from 'Google Tag Manager'? I am not sure whether you are trying to trace the URLS in clientside or server side?
I have a blog with WordPress and I am using a plugin for the ratings of my posts.
Every time a reader rates an article it creates a cookie just for that article. And every time a reader loads a new page it loads all the cookies for each article he/she rated.
Here is a screenshot of what a reader sees inside his Inspect Element:
Should I modify the plugin and put all this information into one or will it not change anything with the performance of the blog?
My opinion would be, yes, combine them into one cookie. However, cookies have a length limit of about 4k, so if the user reviews a ton of articles you will run into issues with storage. With this approach, you could try segmenting the cookie into multiple compiled cookies, but then you run into issues with checking lengths and end up with a bunch of random code.
What I would do in this situation is assign a user ID to the person and attach that ID to a server-side tracking mechanism. Instead of creating a cookie for each rating, you simply create one cookie (I would recommend PHP sessions). Then attach each review with the ID and the rating as post_meta for the article. Then the cookie would always be the same length, and it would tie the user back to the reviews that they completed. This also allows you to group your reviews together by a single identifier, which would allow you to transfer the reviews to, say, a user account.
Been trying to get this working for a few weeks now. Any help is greatly appreciated.
I have recently upgraded to Universal Analytics and managed to successfully set up cross domain tracking with the autoLinker but I can't get my Analytics Experiment to pass the _ga variable when redirecting the user to a domain part of the experiment.
Setup
Both domains have two trackers, one (t0) which they share [UA-xxxxxxx-5] and one (domainUniqueTracker) which logs to a trackingId unique for that specific domain ([UA-xxxxxxx-1] for main domain and [UA-xxxxxxx-14] for new experimental domain).
Linker is loaded on t0 to enable sharing across domains.
Linker is loaded with an array of domains, including the domain I'm trying to send traffic to via the experiment.
Experiment is created on shared trackingId [UA-xxxxxxx-5].
Context
My company has a product called LIME Pro where we until now have had info about on our company web page. Now, as an experiment we have created a one-page about the system on a separate domain, and they want to see which page (old or new) attracts most leads.
Old product page within company web page (experiment code installed there)
http://www.lundalogik.se/crm-system/lime-pro/
New product page on separate domain (shares trackingId with main domain on tracker t0)
http://www.lime-pro.se
Problem
If I visit www.lundalogik.se and from there click on a normal link to the new, external site (normal anchor link on dummy-page lundalogik.se/experiment/) the clientId is successfully passed along in the URL and the tracker at the external site recognises this and starts using the clientId.
But if I browse to the page where the experiment code is installed, I am redirected to the external site without the clientId being passed along, so the tracker at the external site generates a new clientId.
Thanks and sorry about long post, wanted to explain in as much detail as I could.
The various linker functions in UA add _ga to outgoing links (form, frames etc.). Since the redirect happens in the experiment javascript the client id cannot be added to the url (which in a way seems to be an oversight on Googles part - it seems they did not anticipate your use case, i.e. content experiments across domains).
I have a few untested ideas to contribute, maybe you can build a solution on top of one of them.
1) Before the experiment code fires push the client id to window.document.location.hash. At least in Chrome this does no cause a reload (as far as I can tell from looking at the network tab). Since the hash is now a part of the url it should be sent along when the redirect fires. Then you need a script on the receiving page that checks the hash for a clientID and passes it to analytics if present.
2) Basically the same, only this time with the pushState method (https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history) which should allow you to provide the query parameter without reload.
3) Make the variation page a page within your main domain. Instead of any content put a javascscript there that reads the clientId from the cookie and redirects to the other domain
4) Same as 3, only serverside (don't forget to include the content experiment parameter in the redirect)
As I've said this is basically thinking aloud but it might provide clues toward a solution.
My apologies for only having half an answer but I got orders from above to drop this before I got it fully working. Hopefully it will still be somewhat helpful for someone looking to do the same.
If you do get the receiving part done, please post your code here and I'll update this answer/reward you with the answer.
OK here goes nothing..
The sending side works and adds the clientId to the hash and it is successfully transfered when the experiment does a cross domain redirect.
PAGE WITH EXPERIMENT CODE
Execute this before you run the experiment code.
var z, y, x = document.cookie.split("; ");
for (var i = 0; i < x.length; i++) {
y=x[i].split("=");
if (y[0] == "_ga") window.location.hash = y[1];
}
PAGE ON CROSS DOMAIN
Here is where I never got to before receiving my orders to drop this. But you would do something like:
checking window.location.hash and if it contains a clientId (window.location.hash.substr(0,3) == "#GA")
check for existing cookie
2.1. (exists) split cookie by "; ", find "_ga" and replace it's value with above hash (remove "#" first)
2.2. (doesnt exist) create a new cookie at domain level and set "_ga=(hash-value)"
initiate google analytics tracker which would assume the visitor already had accessed the page before and accept the client-id from the cookie
live long and prosper
So, sorry again for an answer is only partially complete but hopefully someone will benefit from this.
Or at least not assume they are mad like I did when I couldn't get it working :).
If the community would like I will of course remove the "accepted answer" if this is considered bad practice (this is only my second post ever to the SO network).
I'm developing ASP.NET applications and stuck with a "problem" relating to resubmit behaviour.
I'm controling the re-submit using a counter in form submit event which disables the submit if it's already been posted.
My application is a 3 step workflow and when the 3rd step is shown the transaction was submited from step2 to step 3.
What's my problem? Well... i want to avoid the user to resubmit the data by pressing the F5 or all other possibility. I don't want to disable the key because may be workarounds.
I'm wondering if i can remove the post data in a HTTP module that runs after the render was completed and right before the response is sent to the user.
You can use Post/Redirect/Get "pattern", where when user post data, you redirect it (after processing submitted data) to another page that will response to get. Just like stackoverflow and another sites are doing.
Here's is the Wikipedia page that explains the Post/Redirect/Get Pattern.
Maybe I misunderstood your question/issue but it sounds like you may be making things harder than they have to be. If you are already keeping track of whether or not the form has been submitted before, why cant you just check that flag on the code behind before performing whatever logic you execute on the submit? If it has already been submitted before, just ignore the resubmit event and maybe set an error message.