My spec says 30 days. I am about to argue for quite a longer TTL, something like 90 - 120 days. What do you think?
This is for a standard website, not an intranet app.
My personal advice would be to do it as a combination of relatively-short expiration cookie with sliding expiration and a long expiration identity cookie.
The first part is your standard week/month-long expiration authentication ticket cookie, which you renew on each request or at certain time interval, or whatever other sliding expiration scheme you want to employ.
The second part is you remember the identity of the user in a half year/year-expiration cookie. This is not an authentication ticket, just an identity reminder, so that if the user returns after their session has expired, they get greeted and you might choose to show some non-sensitive personal information, like number of emails in inbox or anything like that, but to actually access any sensitive information, they need to authenticate themselves.
This will give your regular users (visiting every day or week) continuous never-expiring session, while still keeping the authentication tickets with relatively short time frame. At the same time, for people that return after more than a month, you can still give them a personalized experience, yet their account is secure. I don't think anyone would actually have a problem, if you ask them to authenticate to access certain parts of their account after a month of absence, even if they'd checked the remember me/remember my password checkboxes.
It Depends is the most natural answer. Additionally, we should also ask the user if it's a personal laptop or shared workstation or a public machine.
If Is it a social network or a mail portal or something similar than 2 weeks. in case of personal workstation >4 weeks. If it's a banking system then there's nothing like Remember Me and persistent auth. In fact session should be terminated for no activity in last 15 minutes.
So It depends.
Its depends upon whos using the system. If its an employee of a company using his assigned computer regularly and one of the intranet site sets up "remember me" cookie it can be longer a year or more.
Related
We have two separate websites on different domains and want to track whether a user is a visitor/member to one via a cookie , so we can use that to influence their experience on the other site. Currently, I have GTM setting a cookie based on whether the user has visited certain pages but I'm tracking the effectiveness of this with a combination of events in GTM and Google Analytics and there looks like a 10% error. I'm fairly new to both GA and GTM so it could be either errors on GTMs side or GAs side. I was wondering if anyone had any experience with setting cookies in GTM and if you think this is a safe way to set the cookie?
The reliability of a cookie set by GTM is not a question.
The real question here is how you conduct your analysis, plus how you expect the said cookies to work.
Cookies are useless across top-level domains for this purpose, so if the cookies are set on one domain, they won't be seen on the other.
You're supposed to reset the cookie on every pageview to not lose the context of the visit.
In case you're measuring your tracking effectiveness against the access log, you have to keep in mind that quite a lot of people use adblockers. 10% of data loss due to adblockers sounds reasonable to me, in case you have a younger or more technically apt audience.
You may skip on edge cases when people visit site A from a normal source, then go to site B, so you set the cookie, but then they go back to site A from site B, and so you reset the cookie again.
I would suggest solving this either with referrer report in GA, or by joining the GTM tracking across the sites via GTM cross-domain linking and then analyzing unbroken user sessions, paying attention to the hostname dimension, and then building your analysis on top of that. If you need to track users being logged in on other site, you can then use a custom dimension for that.
I've been scouring the net for ages with this one, and I'm not sure if there is a solution at all, but thought I'd post and see if there's a response... thanks in advance!
Several of our customers (who we build websites for) have their Facebook feeds brought into their website (and their Twitter feeds). Before the removal of the offline_access permission, this was no problem. We'd set our app up, authenticate the account, get the access token and then we could bring in the live feed into their websites forever. However, now with the new system, there doesn't seem to be a way of doing this without human intervention.
Essentially, we have these websites bringing in the feeds from the relevant Facebook accounts, with the long access_token (60 day token). However, when this limit is reached, there is no "user" to re-authenticate the app, as its just the server that makes these requests. Is it a case of having to set reminders for all these accounts, and then every two months we (as the web agency) have to log in to all the accounts and get new access tokens to provide to the scripts so they can carry on working? Or is there an alternative which I am just not seeing?
Thanks again!
Neil.
There is no alternative that I know of. Once the token expires after 60 days, the user must re-authenticate.
No alternative way, user must login to provide you the new access token
https://developers.facebook.com/roadmap/offline-access-removal/
According to new EU laws I have to ask my users to opt into having cookies installed on their computers.
So every time I want to set a cookie I have to see if the user has opted in and if they haven't I shouldn't set the cookie.
When they come to the website a popup will ask if they want to opt in. Should they click "no" I cannot put a cookie on their computer to say they've clicked no. How do I then know, as they go through the website, that they've clicked "no"?
Do I just have to show the popup every page they go to? Or store it in a session variable? (is using sessions still ok under the new law? I assume a cookie is set with the session key?).
Thanks
I'm not a lawyer but I've been reading up on this recently and it is quite clear under the new regulations not every cookie is considered equal and opting in is not required for all of them.
The regulations are most keen on ensuring that cookies that allow tracking of users actions/data between websites must have an opt in, at the other extreme, cookies that contain no personal information and are, for example, only used for security on one particular site (like a session cookie) may not need permission at all.
The UK ICO website has some very clear pages & PDFs (including: http://www.ico.gov.uk/for_organisations/privacy_and_electronic_communications.aspx) on the subject and is definitely worthwhile visiting.
I have a page where user is asked only for the payment amount, then user will be redirected to another website where the payment will be processed, I want the amount to be set on the redirected page without using querystring,cokkie, etc..
I tried to use web service but here is my challange:
user enters amount on the website.
webservice is called and set the amount to ex:400$
then user is redirected without any query string to another website.
Now:
how this payment website will know that this user is the user entered 400$ on the redirecting page?
I can count on approaches more secure than this also.
thanks
I have made some research on net and asked my experienced friends, the answer is "impossible" this way.
Because redirected website somehow identify that user and there is no solution without querystrings or browser related components,
Here is my friend's advice and i am little bit satisfied, not totally :)
He calls this approach as ticketing,
First create a datetime.now integer, with that number add id and amount of money to be processed.
Then make a complex function to encrypt data. take square of every odd digit then divide to 7 etc.
then on the other website, decrypt data and check datetime if its within 5 minutes for example,
the link is valid.
You have to pass the data to the other website somehow.
Cookies wouldn't work due to domain restrictions.
Query string or form posts could work, but you don't want to use query strings.
Alternatively, if both sites share infrastructure, you could use that to share information - for example if they both have access to the same database, you could use that to share data (though you would still need to identify the specific user to both sites).
The way the service would have to work is to give back some token, probably a GUID, that the site will then look for in the querystring of an HTTP request, to identify the owner of that pre-populated data. You then tack that token onto your redirect, and the client makes a request that causes the payment site to go pull the pre-loaded data for that client.
You still have to use a query string, but now, the query string doesn't contain any human-consumable information; they can't identify their $400 amount in the query string and change it to a different amount of money. If they change the GUID at all, the request will most likely fail as that GUID won't exist in whatever datastore of pre-populated data exists behind the payment site.
Contact the website/web service/gateway. They will provide you the API which will define parameters and methods to accept payment amount. If you are the author of such service, provide mechanism to accept such parameters from your caller application. Communication should be secure, using SSL.
For example for payment gateway Paypal, check this for ideas:
Use of the PayPal payment system in ASP.NET
Have a look on wikipedia.
Shortly the answer is impossible this way, because somehow the redirect website should identify the user, all the ways are browser related or ip ( which can cause many issues later)
I've a forum where anonymous is allowed to post, protected by CAPTCHA. For users convenience, I set a Cookie for such a user which lasts about a month so the user does not get the CAPTCHA over and over again. In the simplest form the cookie is called no_captcha_for_one_month and it's value is 1. When the user returns and posts anonymously, he gets not CAPTCHA.
Anyone seeing the flaw? A forum spammer just needs to fill out the CAPTCHA correctly once and use the cookie information for his bot and there he goes.
I thought about getting creative and using a server-side hash which includes e.g. users IP address and some secret salt to generate the cookie value, but it would still be valid for this IP address, of course.
Someone I get the impression the question is silly and I try to solve something unsolvable.
I would recommend implementing your cookie value + salt implementation not to solve your problem but for security reasons. As explained by this blog post wordpress had a similar, albeit it much more severe, problem due to poor cookie security. In your case a determined spammer could always bypass your CAPTCHA even if the cookie had expired.
In order to solve the proposed problem the only solution that is coming to my mind would be to implement a Forced CAPTCHA algorithm that would override your newly secured cookie if it felt the user was being spammy. Off the top of my head I would use attributes like time since last post, number of posts today, the length of time it took to compose the message on the form, etc.
Edit: I should also mention that you can make your forum less attractive to spammers in the first place by implementing the rel="nofollow" attribute on user submitted links. See Wikipedia.
with such a solution it is always possible to use the cookie for a bot. no matter what you try.
As said below, a cookie can easily be taken from a browser and pasted in a bot code, so the solution isn't robust.
Other solutions:
Find some users posting a lot in the forum and ask them if they are volunteer to be moderator. A forum like the AutoHotkey one uses this system, and this works fine. Spammers tend to avoid active forums where moderation is fast and efficient. They prefer dead forums...
Limit the number of anonymous posts per IP address. Can be annoying for users, but can avoid spam flooding. Should be set up only if you experience such flooding.
Even worse, because you are using a cookie, the spammer doesn't even need to do the CAPTCHA once. Cookies can be changed by the client, they are sent by the browser with the page request, so the client can send whatever it wants. In fact spam requests would come from a script, so it's even easier to fabricate the cookies.
Storing the variable server side sill solve the problem I've mentioned; You set a random hash as the cookie, and have a table that stores the CAPTCHA status on the server. For the spammer to get no CAPTCHA, they would have to guess a hash that has the correct variable stored server side, shich is very hard to do.
The problem you mentioned; the fact that once a month might not be long enough to deter a spammer, you can't get around that. You have to show a CAPTCHA to every real user, as often as you want the spammer to enter one as well. Remember, a CAPTCHA is necessary because you can't tell a spammer from a normal user.
You should have the CAPTCHA show often, it will convince people to sign up anyway.
Encrypt the time (in pico or nano seconds) set it as a input value () & set it in your DataBase with a column name 'hash'
set that in every page & see if it matches the DB.