231–240 of 270 posts
Earlier quoted context omitted.
How does it prevent squatting in any way?
At least it makes it easy to see the difference between std / official packages (not prefixed) and others.
Earlier quoted context omitted.
> Sure you can't search for a name of a company or a project and expect it to be related to the company or project. But there's no way to solve that. There's a way to solve it partially: you can have a special part of your namespace tied to domains and require that eg com.google.some-package be signed by a certificate that can also sign some-package.google.com Of course, there's no guarantee that https://company.com…
That just makes package names harder to remember and type (and actually less secure as more prone to typosquatting and backdoors in seamingly harmless pull requests) for no benefit. Keep in mind that the majority of package by far don't come from companies in the first place, and requiring individual developers to have a domain of their own isn't particularly welcoming. It's going to be tons of complexity for zero ac…
Earlier quoted context omitted.
> if you store session data on the server, identify the user using the Authorization header. And by what miracle browser would send Authorization header? Who sets it? For which domain it could be set?
Take a look at how basic auth is implemented in browsers today. Now imagine expanding it to (a) provide a much nicer and somewhat customizable UI for entering your credentials and (b) using proper encryption.
Earlier quoted context omitted.
Identifier in local storage could be stolen by 3rd party JavaScript. Anybody who wants to use local storage for sensitive information should read why there is a httpOnly cookie attribute.
If you are running third party JS on your site they can just make requests to your server now. Once JS is loaded it is running in the context of your domain. No they can’t do it once the user closes the browser but third party JS is XSS in action. And I am not suggesting using local storage for it. I am suggesting adding browser support for standard/generic login UI. Basically think basic auth, just not so basic.
It's like technobros trying to invent an inferior train with each pod iteration.
The "law" is: "Be liberal in what you accept, and conservative in what you send."
But here the problem is caused by being liberal in what is sent while being more conservative in what is accepted. It's using invalid characters in the cookie value, which not everything can handle.
Following Postel's law would have avoided the problem.
What?
Parse a cookie with http://php.adamharvey.name/manual/en/function.http-parse-coo...
Send a cookie with https://www.php.net/manual/en/function.setcookie.php or https://www.php.net/manual/en/function.setrawcookie.php
Or if you have to check how php populates the $_COOKIE superglobal I think it is somewhere is this file: https://github.com/php/php-src/blob/master/main/php_variable...
Earlier quoted context omitted.
Isn't that just the feature working as intended? Of course it is possible to introduce a bug by setting or not setting a cookie somewhere where it should/shouldn't be set. I've never found a use for path-based cookies personally, but I'm not sure this is a particularly compelling example.
The typical example of a path-based cookie is the "remember my login name" feature, where you want the cookie with the user name only available on the login page. (And you cannot use session storage because you want it to work whilst logged out.)
Earlier quoted context omitted.
At work, whoever designed our setup put the staging and dev environments on the same domain and the entire massive company has adopted this pattern. What a colossal mistake.
I had the option to re-use the prod domain for non-prod a few years ago (the company's other two projects use the prod domain for all non-prod environments). I didn't really think about cookies back then but it just felt like a generally bad idea because disastrously messing up a URL in some config or related service would be much easier.
Stage, it depends - if you want stage to have production data with newer code, and are fine with the session / cookies being shared - host it on the same domain and switch whether users get stage or prod based on IP, who is logged in, and/or a cookie. That way your code doesn't have to do anything different for stage vs prod every time it looks at the request domain (or wants to set cookies).
If you want an isolated stage environment, why not just use a separate top level domain? Otherwise you are likely seeing yourself up for the two interfering with each other via cookies on the TLD.
Earlier quoted context omitted.
The typical example of a path-based cookie is the "remember my login name" feature, where you want the cookie with the user name only available on the login page. (And you cannot use session storage because you want it to work whilst logged out.)
You don't need to store multiple login names for seperate pages though, so why can't this just be a site wide cookie?