Hi there,
Thanks for your reply, I appreciate it.
Apologies I wasn't more clear, but yes, I mean "a HTTP request to the
embed.domain.com site must only get a response if the request was made
by a user clicking a link on the docs.domain.com site"... Am I correct
in understanding that you mean it's not reliable as headers can be
spoofed? In any event, I just want to brainstorm some implementations of
how to do that even and weigh up the pros/cons...
I should also explain more!
The end goal is to run Mediawiki on "embed.domain.com", but to not have
the Wiki accessible to the whole world. At the moment, it */is/*
accessible to the whole world but I have it locked down so that all
pages require a login. But that's undesirable for our users though as
it's one more username/password for them to remember and that's annoying
for them when the whole purpose of heading to the Wiki in the first
place is likely to find information to help them with using their other
accounts on our infrastructure.
More context is that "docs.domain.com" is where a Nextcloud instance is
served from, and so the desired result would be to only allow access to
the Wiki /through/ Nextcloud (by adding the Wiki to Nextcloud as an
"external site"). And so for experimenting with the current situation
where the Wiki is locked down and requires a login, to get around that,
I've looked at OAuth, but Mediawiki does not support Nextcloud as an
OAuth provider (as far as I can tell), and without going into other
crazy login setups like LDAP, I'd actually prefer to try and go the
other way---unrestrict the Wiki so that viewing and editing pages don't
require a login, but the pages are only served *if* they've been
requested through Nextcloud (from docs.domain.com)...
Maybe this is impossible, but can anybody imagine how this could be done
and what the pros/cons of the approach could be?
And as for the reason to prevent the Wiki from being accessible to the
world in the first place, that is: while there wouldn't be extremely
sensitive information on the Wiki per se, some content would reveal in
some instances the general backends of some of our infrastructure, which
the whole world doesn't need to know...
So yeah, any questions/ideas/suggestions/commentary welcome!
Thanks,
Jore
On 15/3/21 1:50 am, Francis Daly wrote:
> On Sat, Mar 13, 2021 at 07:56:35AM +1100, Jore wrote:
>
> Hi there,
>
>> I have pages served from "embed.domain.com" that I'd only like to be
>> accessible when they're embedded in files served from "docs.domain.com"
>> Is it possible to lock down "embed.domain.com" so it can only be accessed
>> through "docs.domain.com"?
> If you mean "a http request to the embed.domain.com site must only get
> a response if the request was made by a user clicking a link on the
> docs.domain.com site", then that can't be done reliably. That's the
> nature of http.
>
> You could do something like block external access to embed.domain.com
> altogether, and use nginx to reverse-proxy requests to it behind
> http://docs.domain.com/embed/, for example.
>
> That would mean that all external http requests would go to
> docs.domain.com; but it still does not mean that a request to
> docs.domain.com/embed/ came from a user clicking a link somewhere else
> on docs.domain.com.
>
> It may or may not match what you want.
>
> Good luck with it,
>
> f
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
