add sharePath url option setting

[maphew]

This is a follow up to #1207 bare2share: adding a sharePath option setting under Other so that the anonymous url path can be / or /foo instead of hardcoded to /share.

The options setting page is setup and works in that the setting is saved, but routing for anonymous user is broken. I'm stuck for now.

(meta: npx prettier has not been run. Also I don't see the control for setting this PR to draft, sorry. Review still welcome though!)

[pano9000]

I've put it into draft for you :-)

will have a look at this later this evening (CET time :-)) - this time hopefully without too much confusion from my side ;-)

[JYC333]

Is this still valid and ongoing?

[maphew]

@JYC333 I still want it, if that counts :). I'm stuck with how to complete the implementation though.

[JYC333]

I can try to take a look if you don't mind

[maphew]

that would be wonderful, thank you!

[maphew]

merge fbe7d64 just catches the branch up to develop right? It doesn't yet attempt to address the anonymous routing problem I got stuck on?

Just checking because with these changes I still get "checkAuth: Redirecting to share path. From: /, To: /share" in console with "Firefox has detected that the server is redirecting the request for this address in a way that will never complete." in browser. However I'm not sure my local dev folder is clean.

[JYC333]

Yes, it's just merging develop for now, still look into the problem. Probably won't finish today through.

[eliandoran]

@JYC333 , have you had the time to look into this one?

[JYC333]

Sorry didn't have enought time to work on this... If you want to take over, please go ahead, otherwise I think I probably can start look into it next week.

[pano9000]

FYI: I'll take a stab at it now

[pano9000]

FYI - having some progress here: https://github.com/TriliumNext/Notes/tree/feat/clean-share-url
(accidentally created a new branch, instead of updating this PR branch, sorry about that).

• endless redirect loop is now gone
• more work to follow

[pano9000]

FYI:
this is what we are working with:

custom sharepath

setting the custom path is working, however it requires a restart of the backend AFTER setting it at the moment.
edit: it works but navigation is buggy, depending on trailing slash or no trailing slash:
there's at least 3 places where the sharePath is used/set, where the trailing slash makes a difference.

1. the option widget
2. auth.ts -> where it redirects to res.redirect(``${sharePath}/``); (adding the trailing slash)
3. share/routes.ts -> where it uses router.get(``${sharePath}/``, matching against the trailing slash

Will need to do some more digging why and how to fix it.

Previous code was trying to deal with it as well, but that attempt was what was causing the redirect loop.

I'm looking into checking how we can maybe change the route path dynamically WITHOUT a manual backend reload — quick forewarning: I will probably not be able finish this PR today

edit: alternative idea: just inform the user that they need to do a server restart, before the change becomes applicable for now → and work on improving that in the next step.

cleanUrl option

I've commented out the code behind this feature for the moment: it's better to work on one feature at a time ;-)
makes debuggin a lot less of a headache :-)

[maphew]

thank you for the attention and work!

[pano9000]

work is now continuing on making the "cleanUrl" work — however quick question: @maphew

What is the idea between using the "clean URL option" vs just using "/" as share root path?

[maphew]

What is the idea between using the "clean URL option" vs just using "/" as share root path?

Hah, I'm having trouble remembering just what was in my mind when I chose those words.

I wanted to accommodate folks who might want to have a dedicated/explicit "anything under this is public" element in the url, and to be able to use whatever word they want for that -- /share, /public, /dielet, tielen, ... (e.g. translations).

For myself I'm happy with the inverse: everything at / is shared unless it begins with whatever the authorized user path is. However I thought it might be impossible to have a root path as shared that contained a private exception -- meaning if / is public you can't have /edit or /mine route as private.

[pano9000]

ok, thanks for the confirmation — my current take on is PR:
I'll finish up the custom share route, and temporarily remove all the "cleanUrl" related stuff.

then we have one PR for the custom share route feature — and afterwards we can have a separate PR for the cleanUrl related stuff (if that is even possible or if it makes sense — I have a feeling that really is almost like something for a reverse proxy — but let's split it into a separate discussion when time has come :-))