Try <a>'ing links

[AbelLykens]

Hope this works, for #1192.

CrudList.vue — The column template now checks for a column.link function. If present, the column content is wrapped in a (renders as ). The @click.native.stop prevents the click from bubbling up to the row's @click:row handler, so regular clicks navigate via the link, and ctrl-click / middle-click / right-click all work natively. Columns without link render exactly as before.
CrudListDomain.vue — Added link: (item) => ({name: 'domain', params: {domain: item.name}}) to the name column. This generates the /domains/example.com URL as a proper href.
The existing handleRowClick is kept, so clicking anywhere else on the row (e.g. the "Published" column) still navigates as before. But now the domain name is a real link with full browser link semantics: right-click menu, open in new tab, ctrl/cmd-click, middle-click, and URL preview in the status bar.

[peterthomassen]

Thank you! I've reworked this a bit as the Vue 3 upgrade which happened in the meantime required tackling this a bit differently (but kept your approach).

[peterthomassen]

Hmm, that didn't work as I had hoped. Opening a domain link in a new tab lands on the login page because the auth token isn't shared with the new tab.

I thought the "Remember me during this browser session" checkbox at login controls this, but turns out that's only about reloading in the same tab.

So, how to get this working? Options:

1. localStorage — shared by all tabs immediately, no handshake. Also survives browser restarts, which the current design avoids; server-side limits (7 d max age, 1 h unused) bound the exposure. The checkbox would become "this tab" vs "all tabs". I'm not convinced keeping DNS credentials alive is a good idea.
2. BroadcastChannel / SharedWorker handshake — a new tab asks open tabs for the token; nothing is persisted, so the datensparsam default is kept. Brief unauthenticated moment (not sure how that looks), also seems engineering-heavy and lastly I'm not sure other tabs could hijack / exfiltrate that.
3. HttpOnly session cookie from the API — covers every tab and removes the token from JavaScript entirely. Requires CSRF, also we'd loose the unusual trait of not needing cookies.
4. Keep the links (for status bar display etc.), but force opening through window.open() where session storage is inherited. This seems best to me, but I don't know if there are use cases that would interfere with. There may be an issue with pop-up blockers, although I don't think at the first time. (Also, it would probably work with
   instead of as well.)
5. I think target="_blank" also shares session context if the link target is in the same origin. We could try to tweak things such that ctrl+click would somehow cause the target="_blank" behavior, whereas a normal click would suppress it and proceed in the same tab. No idea about interference with popup blockers, non-visual interface etc.

@AbelLykens You seemed to find it important that there are actual links. Is there a specific reason for this implementation choice, or would you be fine with any implementation as long as the functionality is provided?

Also, @nils-wisiol.