4 ms·
The only difference between your “DOM cookie” technique and a browser cookie is that it sounds like you’ve (re)invented a session cookie that only works with si
by wolfgang42 2y ago
The only difference between your “DOM cookie” technique and a browser cookie is that it sounds like you’ve (re)invented a session cookie that only works with single-page apps. Either way it boils down to an opaque session ID token which is stored on the client and sent to the server with every request. You could do the same expiry/crosschecking/validation on the server either way; it makes no difference for security how the client stored it.
Frankly, this entire codebase is full of code smells that are hallmarks of Dunning-Kruger security (I should know, I was like that myself once!) and the fact that you haven’t learned anything in the 3 years since it was written is alarming.
- zelon88 2y agoSo my original comment was accurate then? > Cookies are entirely a design choice, and a lazy one at that. It is entirely possible to identify, authenticate, maintain session, and store data about a user on the server completely without cookies. * By your logic, you're just to lazy to do this better than me and it's just easier to throw banners at everyone?
- wolfgang42 2y agoYes, it’s a design choice, in that you have chosen to design something worse for the sake of feeling industrious. There is no need to show a consent banner for authentication cookies (these are considered “Strictly necessary cookies... essential for you to browse the website and use its features, such as accessing secure areas of the site”). On the flip side the directive on tracking consent covers any method of tracking, it doesn’t let you go “nyah nyah, I didn’t use a ‘cookie,’ I made my own and called it something else!” so if you think you would need a banner for a cookie, you will need a banner no matter how you do it.