Haven't seen it in a long time but websites used to keep the session id in the query string

That's a bad idea because it is visible on the UI and anywhere the user copies/saves the URL, and it would also still have all the downsides that cookie-based tracking enables. Cookies are how HTTP application sessions work, it isn't possible to just get rid of them, without replacing them with something identical in functionality even if you change the name.

Wouldn’t that make the session key show up in log files on the server and on any network infrastructure between the server and the client?

Assuming https, the querystring is encrypted, so should be safe in transit. Could show up in server logs though, I'd think. The server can log a lot of things though, depending how it's configured.

Session ID in URL is a terrible idea because guess what, people share links with each other. Example: A school enrollment system in Finland logs you on with another person's account if they give you the link to a page they are viewing (which they often do), because the session is in the query string.

Its possible to do this on the server side. Form submissions don’t require JavaScript, and authentication post submission can be done with cookies. Or if you want to go way back http basic auth.

To be clear: I support JavaScript on the web, just hoping to answer your question.

Also sorry: I answered the wrong question. Http basic with would still work.

I remember a time when basic auth gave you a unique url and the referrer was used to validate you. This was easy to break because you can fake the referrer.

I think the parent meant authentication persistence, without cookies.

> authentication post submission can be done with cookies

I think the comment you are replying to is reacting to the top-level comment which is advocating removing cookies.

Yep. My bad.