The URI parameter must be accompanied by the session token and encrypted login credentials as well via POST.
So unless you steal the username, hashed password, tokens, and URI parameter before the expiry of the token then you aren't hijacking a user session.
Let's say the cookie expiry is 10 seconds, or until the user clicks a button on the page.
Any MITM attack is going to have to intercept the HTML over clear text http in order to steal the DOM cookie. That attack would also work on a regular cookie. But with my design the attacker only has 10 seconds to deconstruct that cookie and use it to steal the session. With a regular cookie they have a lot more time.
The only other way to hijack the session would be local malware or browser extension, which would also work on a regular cookie.
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.
> 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?
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.