Possible to make subdomain only accessible through 'embed'

Francis Daly francis at daoine.org
Wed Mar 17 09:22:21 UTC 2021


On Mon, Mar 15, 2021 at 04:24:27PM +1100, Jore wrote:

Hi there,

> "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?

It's not reliable because HTTP says that every request is independent. And
requests to two different hostnames are "extra"-independent.

If you want to try to add some control, you have to decide what level of
"allow what you want blocked" and "block what you want allowed" you are
happy with.

> In
> any event, I just want to brainstorm some implementations of how to do that
> even and weigh up the pros/cons...

In principle:

you could (dynamically) change all of the links on docs.domain.com
pointing to embed.domain.com to be limited based on time and whatever
other request-based criteria you like; and then change all of the content
on embed.domain.com to include similar links; and change the service
that provides that content to validate the requests before continuing.

In practice: you probably don't want to do that.

> 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.

I don't fully understand what restrictions you want to apply here. (That's
ok; I don't have to understand it.)

Maybe you could allow unrestricted access to the "here is how to reset
your password" information, and require a password for everything else?

Alternatively: if you were to reverse-proxy the MediaWiki instance at
docs.domain.com/embed/, then you could potentially set a cookie on
docs.domain.com, and require that a suitable cookie is present for any
requests to docs.domain.com/embed/.

That might be the closest to what you want?

Good luck with it,

	f
-- 
Francis Daly        francis at daoine.org


More information about the nginx mailing list