feat(ui): Add /a/<asset-tag> for use with QR codes on asset stickers

[archessmn]

No description provided.

[LooFifteen]

GET /a/{tag} should probably 307 /asset/{tag} for authenticated users. Is that possible? I assume GET /v1/assets/{tag} will be needed beforehand?

[archessmn]

Yeah definitely possible, but yeah would need the api endpoint first to be useful

[LooFifteen]

#61 has landed, so this should be possible now.

[ashhhleyyy]

just a thought, but is it worth having it update the browser url to always be the asset id rather than the tag, so that the id is always the canonical url for an asset, while still allowing you to quickly access an asset via its tag just by putting it in the url (the use case i can think of is an external doc referencing a specific item, which could become outdated if the asset gets a new tag, where making the link users copy from the address bar would prevent this in a lot of cases)

[archessmn]

So just redirect to /assets/$id if it gets /assets/$tag?

[ashhhleyyy]

yeah

[archessmn]

Pushed that change

[LooFifteen]

GET /a/{tag} should probably 307 /asset/{tag} for authenticated users. Is that possible? I assume GET /v1/assets/{tag} will be needed beforehand?

I've been thinking about what I said here, and maybe I was stupid. /a/ to /assets/ conversion is probably best being a reverse proxy task, rather than ours. Possibly a better flow is:

• Reverse proxy handles GET /a/{string} -> 308 /assets/{string}
• CHDRMS handles GET /assets/{string} as contact page
• CHDRMS handles GET /(authenticated)/assets/{tag} as 307 /(authenticated)/assets/{id}
• CHDRMS handles GET /(authenticated)/assets/{id} as asset page.

Let me know if this sounds stupider.

[archessmn]

I think no, adding the requirement of configuring a reverse proxy to use a feature anyone using QR codes will use seems pointless, as it's all client side as well there's no such thing as 307 redirects so you'd have to do that from the backend.

[LooFifteen]

That's fair enough. Although my final question about that would if it's possible to also have the contact page on unauthenticated /asset/{tag} so a reverse proxy configuration is still possible? At the moment it redirects to login, which is quite helpful - so I'm not sure of a good solution to this.

[archessmn]

/asset/ or /assets/? Current authenticated is /assets/. Also "so a reverse proxy configuration is still possible?" doesn't make sense to me, is there a reason you'd actually want to use a reverse proxy for this at all? Can you not just have something on the backend do a redirect instead? Just not understanding why the reverse proxy is involved.

[LooFifteen]

Sorry, yes, I did mean /assets/. My example for reverse proxy usage would be the case where I would set up GET https://lu15.dev/URY-0-0000 to 307 https://rms.lu15.dev/assets/URY-0-0000, effectively skipping the CHDRMS /a/{tag} page altogether, reducing the number of unnecessary redirects. This hypothetical setup would mean the contact information will never be shown.

[archessmn]

So what you want is one page that's dual purpose for both authenticated and unauthenticated users? The setup you described would work currently for authenticated users, and once I push the changes Ash suggested you'd still get "redirected" (it's js, so not an actual redirect) when you navigate to the /assets/$tag page so you end up with the ID instead, one way to solve this would be to have /a/$tag redirect you straight to /assets/$id instead of /assets/$tag perhaps? Same number of "redirects". Also due to how the /(authenticated)/ routes are handled any unauthenticated requests get sent to login, and doing something special just for that page seems not worth it, as it basically just means combining the two existing pages along with all the auth logic.

[LooFifteen]

If it's not worth making the page dual-purpose, don't bother. The suggestion posted by Ash is a good idea and my hypothetical scenario still works with the current implementation anyway, just not bar for bar.