Possible to make subdomain only accessible through 'embed'

[Francis Daly]

On Wed, Mar 17, 2021 at 11:21:58PM +1100, Jore wrote:
> On 17/3/21 8:22 pm, Francis Daly wrote:

Hi there,

> > 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?
> 
> Is this all possible through a nginx config? If so, are there some examples
> you could point me to?

I have not tried it; but some web searching indicates that it is possible
to install MediaWiki to be below /embed/ on the embed.domain.com server;
and you might also be able to set $wgServer to tell it that it "really" is
on the docs.domain.com server, and you can optionally set $wgSquidServers
so that MediaWiki will use the X-Forwarded-For header.

In that case, the nginx side would basically be

  location ^~/embed/ {
    proxy_pass http://embed.domain.com;
  }

And you might want to include "proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;" or similar things too.

Also in that location{}, you would do whatever tests you want, to see if
this request should be allowed or not. That might be an "if $cookie",
or a fuller auth_request, or something written in one of the embedded
languages.

In this case, the first allow-or-not decision is made on the nginx side,
without involving MediaWiki at all.

> Or do you know if I'd have to get Mediawiki modified to do something like
> this?

I don't think a MediaWiki code change would be needed. There might be
useful config changes that could be made, but may not be compulsory. I
suspect that things would work more cleanly if MediaWiki knows that it
is below /embed/ instead of being at /; but it might be possible to work
in the latter case.

Good luck with it,

	f
-- 
Francis Daly        francis at daoine.org