Hot answers tagged

64

A socket identifies a connection. Cookies are usually used to identify a user. If I open two browser tabs to SE.SE, I will have two connections and thus two sockets. But I want my settings to persist across both of them. (In fact, typically, a browser opens multiple sockets for one page in order to speed up page load time; I believe most browsers have a ...


20

TCP sockets are designed to be stateful so in general they are used to identify sessions. Protocols like SSH and ftp do exactly this. HTTP is designed to be stateless and each connection is only associated with a resource to be downloaded. After a resource is downloaded the TCP socket that the HTTP request rides on is closed. The original reason for this ...


18

Sometimes you can use IP address. If you're on a LAN or are otherwise dealing exclusively with users that have IP's statically distributed to single clients, using that address is perfectly fine -- sometimes preferable and necessary. But, usually you can't. If you're running a public site, most of the IP addresses that hit your server aren't static or ...


11

Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles) Cookies are tuples key-value originally addressed to retain data related to the client activity. This retention is what we know as session or application state. Fundamentally, they were made for holding the state of web ...


10

Three more reasons to add: Multiuser workstations and terminal servers exist. Many users could be running completely independent browser processes in separate sessions. IP addresses aren't persistent. It could be reassigned when a DHCP lease expires. The application should support roaming. For example, a user on a phone might drop out of WiFi range and ...


10

But I don't know how should I encrypt password that when I save for autologin. Autologin is not based on the password used in a manual login. There is a separate credential (based on identifying and non-identifying information) that is generated after a successful login, and that credential is stored on the client in an encrypted cookie or similar storage ...


7

Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles) Your definition of cookie doesn't really describe what they do. A cookie is a key-value pair that is set via HTTP response header (Set-Cookie) by the server and stored by clients that support them. Cookies are sent back ...


7

To expand on Robert's comment, from the moment you have a malicious program running on your machine, using your cookies is not the worst thing it can do to you. It can, among others: Add a certificate to your machine and change the DNS records. Now, when you connect to https://bank.example.com/, you reach the servers of an attacker, and his website looks ...


6

Remember me cookies are a special kind of cookie because they allow the user to bypass providing the authentication information, while other cookies may just track what pages you have been on or what is in your shopping cart as a non logged in (unauthenticated) user and aren't really risky except to the extent that such information is assumed to be private. ...


6

What you're describing is the same spirit of a JWT. JWTs aren't encrypted, but they're signed so you can verify authenticity. Nobody can forge a JWT unless they've cracked your key. I would recommend using them instead of rolling your own because JWT are being used by many organizations for several years now. JWT verification and signing libraries are ...


5

Syntax setcookie(name,value,expire,path,domain,secure) path Optional. Specifies the server path of the cookie If set to "/", the cookie will be available within the entire domain. If set to "/test/", the cookie will only be available within the test directory and all sub-directories of test. The default value is the current directory that the ...


4

Yes, the client - assuming a web browser - would send the cookie for that domain. You dont need to send it each time. Though a lot of applications do send the cookie back with each page so as to extend the expiration of the cookie. You probably dont need the 'success' field - either the session id stored in the cookie is going to be valid, or it isnt. ...


4

If you want the longest and most flexible, implement OpenID and require them to register. Done correctly, it's little more than a couple of mouse clicks. Check out how easy it is to join one of the stack exchange sites. If that's too much work for you/your users, then a cookie is really the only good choice -- you could generate a unique query string and ...


4

An interesting approach might be to allow the users to create a password for each entry. No username/profile/registration - just along with the post - a password. The password should probably have some strict guidelines to keep your site from getting bruteforced into wall to wall spam. I'd probably make it timeout after a reasonable amount of time too (...


4

Going against the law is not an option: first it might make you loose more visitors (i.e. those who count on you to respect their privacy). Second, GDPR fines calculated as percentage of your global sales, might wipe out your profits. Fortunately there is a proven solution for your problem: the two-step like-button. When the user goes on the page, the ...


3

The situation that you are referring to would happen if the client is compromised. This is a real concern, but in that case any protection that you implement is trivially bypassable by having the compromised client do whatever needs to be done. So you can do an IP address check, but it won't actually help much. That said, the data structure that you have ...


3

We run an AJAX call on our site which sends a heartbeat to the server once every couple minutes, keeping the session alive as long as the page is open on the browser. Once the page is closed, the session expires on its own. Here's a snippet of the code I wrote to accomplish this. Please excuse all the cardiac terminology :) /** * Heartbeat singleton */ ...


3

Simply store the entire shopping cart and contents in a cookie or other client side storage. Then you don't need the database and there is no risk of a user gaining unauthorised access. Plus it will scale better. The problem with shopping baskets in databases, especially for anonymous users is how long do you hold them for. During peak times such as a ...


2

The standard to support IRIs states the character encoding for such URL must be UTF-8. It also states in 4.1.2.4 in HTTP State Management Mechanism that the path is that of the directory part of the URI (i.e. the encoded IRI). Eg. the directory '/å/' has Cookie path '/%C3%A5/' even though the response header states the content-type is ISO-8859-1. %20 is a ...


2

It's just an example of tech support not knowing a lot about computers. I've had similar experiences with our tech support suggesting to customers that they turn of virus scanners, for instance. It's very much a cargo cult, driven by a business desire to keep expenses down. As a customer, it's therefore a sign to avoid that company. They will be saving on ...


2

Using IP address as identifier is generally not recommended, as it is not what IP address is meant for - functionally it is a plain address for routing from a to b, and it tells nothing what is before a or after b. In example, same IP address may be shared by a number of natted devices, most common cases being a) a provider dynamically assigning a pool of ...


2

There's HTML5 local storage, which allows you to keep data without it contaminating the HTTP requests you make. It's intended for pretty much exactly this use case: complex Javascript applications that want to store persistent information locally. http://www.w3.org/TR/webstorage/ Note that REST doesn't mean banning all state from the server, sometimes you ...


2

That is relatively safe, providing that you use SSL (HTTPS, use ssllabs to check the security of your site), and you configure your cookie to be domain-specific, have an expiry date not too far in future and be "HTTP-only". Use mcrypt for encryption (there's support for that in PHP) and the salt key should be reasonably long, and kept SECRET, or change for ...


2

Here's one way to think of it: It is impossible for the server to directly set a cookie. The server sends an HTTP header, which tells the client to set a cookie. It's the same way with JavaScript or hand-editing, because it is assumed that if the client can change the cookie, the server can't complain (unless the request is malicious). EU law also ...


2

The best way to make the browser stop enforcing the ;secure flag is, don't send the ;secure flag to the browser when setting the cookies. Configure the server to leave off the ;secure flag during those activities where you want to use HTTP. If the server does not send the ;secure attribute, the browser will allow you to send the cookie over HTTP. If you ...


2

Wiring as Answer as it exceed comment limit. You need to follow HTTP protocol. saving password by some homegrown solution is inherently unsafe. Even if you dont have access to server you have access HTTP endpoint? Do a normal login, see what cookie is set. It should have the session. Which means you can do the same on the client. Save the session is what I ...


2

Security is a matter of degree, and reasonable expectations. All true multi-user-systems (Windows NT, Unixoids, ...) try to make sure that one users programs cannot interfere with another users data and programs. While they generally also allow for more protection (using services running from a different account, for example the system-account), that's ...


2

I agree with nadir that this is not a space where you should 'roll your own' but I think it's long overdue that we start talking about how these things go wrong because it's the app developers that are creating these vulnerabilities and we need to learn how to stop doing that. The biggest problem I see here is that you are storing the exact value needed to ...


1

Cookies are transferred "with each subsequent http request", on that browser. Cookie storage is browser-specific. Unless browsers choose to share their cookie cache somehow, or read those of other applications (which would brand them as malware pretty quickly), they only know of the cookies set in that browser


Only top voted, non community-wiki answers of a minimum length are eligible