-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bare2share - Redirect bare domain to defined #shareRoot #1207
Conversation
The last known good state before I got sidetracked into docker changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
thanks for the PR – just a couple of general comments and a tiny request to fix the i18n part.
apart from that:
Could you kindly run prettier on your modified files?
This will automatically format the files in accordance with the project's defaults.
You can do that via npx prettier --write ./path/to/your/file-or-folder
src/public/app/widgets/type_widgets/options/other/share_settings.ts
Outdated
Show resolved
Hide resolved
# Conflicts: # src/public/translations/en/translation.json
Thanks for review @pano9000, I appreciate it. I believe I've addressed what you pointed out. A caution for anyone else following: it's not safe to run prettier globally on the repo, much more than a handful of files will be changed! 😆 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@maphew thanks for your changes, sorry for this, but there need to be some additional changes:
Since the option is now a boolean, you will need to also change all of your code to handle booleans, instead of strings (e.g. comparison like options.redirectBareDomain === "true"
→ can be dropped completely)
let me know, if you need any assistance with that or if there are any questions
}, | ||
|
||
// Share settings | ||
{ name: "redirectBareDomain", value: "false", isSynced: true }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you use boolean values here please :-)
(i.e. just drop the quotation marks :-))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done. When I did so intellisense complained about boolean not assignable to type string. Consulting LLM (Claude Sonnet) about this led to commit 15fc572. I don't know if this was the right thing.
src/services/auth.ts
Outdated
@@ -15,7 +16,8 @@ function checkAuth(req: Request, res: Response, next: NextFunction) { | |||
if (!sqlInit.isDbInitialized()) { | |||
res.redirect("setup"); | |||
} else if (!req.session.loggedIn && !isElectron && !noAuthentication) { | |||
res.redirect("login"); | |||
const redirectToShare = options.getOption("redirectBareDomain") === "true"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since getOption should return a boolean, you can drop the comparison entirely here.
I'm perfectly fine with this. Java/typescript is whole new world for me and I appreciate the scrutiny. |
thanks for your changes and additional commits I'll get back to you with more details on this evening after my work -> I might've overlooked something here (or the Type Definitions in the option_interface are wrong/weird): it seems like options are actually stored as strings, but can get retrieved as their "intended" type via the extra methods provided in i have to admit, that is a tiny bit confusing and also it does not look like there is any consistency across the codebase on when what is used either! :-) if you don't mind I'll lend you a hand though with that |
yes please, for your help (and explanations) :-) |
@maphew sorry mate, I did not get to work on this directly today, but working on my other "friendly numbers" PR did make me grasp a better understanding of the optionsMap vs optionsService thing, that we were talking about in my comment above. I'll provide you with some suggested improvements tomorrow morning before I head to work – then we can finally get this one ready for Elian to merge :-) |
so, I took a look and noticed that I mixed up the "option" service from backend and the "option" service from the frontend: long story short:
Sorry for the extra work and confusion I may have caused! Afterwards there is only one change I would do in the TPL, to make it look and behave the same as the other options: I'd change your current TPL with the one below
this will make it look better integrated with the rest of the options: apart from that: I've tested it and can confirm that it works → we should document the requirement to have a "#shareRoot" tag set, because otherwise you are greeted with: -- Thanks for your work here! |
thank you for the detailed help. I've made the changes. The I'm experimenting with:
but don't have it working yet. I'll do that as a separate pull request since I'm not all sure if I can succeed. |
thank you! |
the validation worked out! And the settings are new self-documented |
Thanks @eliandoran, I agree on layout changes. As for the redirect change, sure! If you think it works. I thought there might be conflict determining if secured and open were on same level (my understanding of routing is very limited). There is a UX gain by knowing that any url starting with |
I tend to agree with @maphew on that we maybe should keep I mean potentially this could still be changed in the future as an option – but I would see it as a separate PR anyways. |
I'm going to take another run at making the target url configurable. #667 included it initially, but the branch was too messed up, and I hadn't considered a target of |
Addresses #658
Adds Options >> Other >> Share Settings:
Requires a note that is a) shared, and b) defined as
#shareRoot