Possible to make subdomain only accessible through 'embed'

[Jore]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20210315/fca4106a/attachment.htm>