Skip to content
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

Add hostname as template param #221

Open
Bored0ne opened this issue Oct 20, 2020 · 2 comments
Open

Add hostname as template param #221

Bored0ne opened this issue Oct 20, 2020 · 2 comments

Comments

@Bored0ne
Copy link

Steps to reproduce

  1. Go to url tab of new external site & add http://{url}

Expected behaviour

Expect to see http://localhost when clicked

Actual behaviour

I'm not allowed to save it with that.

My reasoning is that I'm on a shitty At&t router & the damn thing doesn't resolve my local server at my hostname from my internal network. Which means that when I'm at home the hostname would be 192.168.1.* but when I'm out it's my domain. I'm okay with this behavior, but when I wanna make my own embedded apps for my local server I can't because it won't resolve when I'm outside the network. I would like it so that this would grab the hostname from the request info & embed it that way.

@madumlao
Copy link

Probably related to and solves the same problem as #120 which I am running into.

Same as above, my internal router (1) doesnt have DNS entries for local machines and (2) will resolve my FQDN to the external IP. The effect is that if I have another app on the same server (eg /transmission, or /jellyfin) and I access from a local IP (eg 192.168.1.x), the iframe loads from the internet whereas nextcloud loads from the local network. This is not ideal as the local network will likely be considerably faster than my router internet and may have relaxed security controls.

In the above issue the request was to allow relative URLs, which was rejected due to compat issues, but this is really the same kind of issue - compatibility / convenience for other apps sharing the same URL scheme. Just to add then, this proposal will need template variables for both the current hostname and protocol to ensure compatbility, so you can put in:

{proto}://{hostname}/something

Or alternatively, revisit the above issue and have logic that will automatically parse

/foo

as an implicit

{proto}://{hostname}/something

which should resolve to the proto / hostname of the current session, possibly falling back to the canonical if indeterminate

@github-actions
Copy link

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the reviewing process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, we would appreciate your feedback on your experience with our community management team.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants