Subdominios compartidos, dúas entradas: quen ve que rexistros?

A Clínica A e a Clínica B comparten unha base de código, dous subdominios e unha mestura de visitantes de oficina e por VPN. Os equipos de rede adoitan configurar as dúas entradas por separado, e iso está ben, sempre que a aplicación non o faga. As comprobacións de abaixo pertencen á aplicación e deben comportarse igual sexa cal sexa a porta que usou a petición.

Primeiro: o nome de host só nomea un inquilino

Resolva o nome de host solicitado contra unha correspondencia que mantén o administrador e rexeite calquera cousa descoñecida. Use o valor de host validado polo marco de traballo en lugar da cabeceira cru, para que un Host fabricado non poida inxectar unha clave de busca. Unha coincidencia correcta di ao código que configuración de inquilino e que imaxe de marca cargar. Non di nada sobre se quen chama pode ver os datos dese inquilino. Manteña esa segunda pregunta nunha función separada cunha entrada separada.

Unha función auxiliar compartida que devolve á vez o contexto e o permiso a partir dunha soa busca de nome de host é o comezo do fallo.

Segundo: a pertenza vén da sesión

Busque as pertenzas activas do usuario autenticado e compáraas co inquilino da primeira comprobación. Un usuario que pertence a ambas as clínicas pode cambiar, pero o cambio debe ser unha acción explícita rexistrada no contexto da petición, non unha inferencia da URL. Un usuario que pertence a unha clínica e pide a outra é denegado, tamén para descargas e chamadas de API.

Probe o caso negativo editando un identificador de rexistro e un parámetro de inquilino. Se calquera dos dous cambios devolve datos, o alcance lese da petición e non da pertenza verificada.

O alcance das cookies e o inicio de sesión único deciden onde se pode presentar unha conta. Non deciden que pode ler esa conta.

Terceiro: a rede non demostra nada sobre a persoa

Unha pasarela VPN autentica un túnel, e unha lista de permitidos pública autentica un rango de enderezos. Ningunha das dúas identifica unha persoa. NAT agrupa moitos usuarios nunha única dirección de orixe, e un rango de oficina fai o mesmo con todos os do edificio. Trate ambos como feitos de transporte e manteña a autorización na aplicación, ou nunha integración que afirme a identidade explicitamente e se revise como tal.

DNS é un terceiro feito de transporte. Unha resposta privada necesita unha ruta privada, e un frontend público necesita un camiño de orixe admitido. Ningún deles leva un permiso.

Unha frase para a parede: a rede decide como chega unha petición, e a aplicación decide que pode ler.

Cuarto: execute a matriz nas dúas entradas

Use contas controladas para exercitar A en A, B en B, A en B, un nome de host descoñecido e unha conta autenticada sen pertenzas. A cuarta e a quinta deben fallar pechadas e nunca recorrer a un inquilino por defecto. Execute a mesma matriz tamén pola entrada VPN, cun tarro de sesión por conta:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

Despois cambie unha entrada da lista de permitidos e volva executar. Un resultado que se move significa que un control de rede está tomando unha decisión de autorización.

Repita a matriz despois de calquera cambio no frontend, porque un segundo camiño de código que omite a comprobación é a forma máis habitual en que esta fronteira se erosiona. O resultado esperado é aburrido: cada entrada produce as mesmas respostas.