htaccess conjunto de cabeçalho condicional está ignorando a condição

2

Estou tentando definir cabeçalhos se a origem for um site específico para resolver um conflito de recursos que estou tendo (usando o Mautic hospedado em um subdomínio).

Se eu adicionar os cabeçalhos para qualquer situação, recebo um erro 500 quando tento usar o Mautic, mas o recurso que está sendo acessado do meu site funciona, portanto, só quero defini-los quando meu site é a origem.

Isso é o que eu tenho:

RewriteEngine On
#preserve HTTP(S)
RewriteCond %{HTTPS} =on
RewriteRule ^(.*)$ - [env=proto:https]
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ - [env=proto:http]

<IfModule mod_headers.c>
    SetEnvIfNoCase Origin %{ENV:proto}://mysite.com ENV_SET
    SetEnvIfNoCase Origin %{ENV:proto}://mautic.mysite.com ENV_SET=0
    Header add Access-Control-Allow-Origin %{ENV:proto}://mysite.com env=ENV_SET
    Header set Access-Control-Allow-Credentials true env=ENV_SET
    Header set Access-Control-Allow-Methods: GET, POST, PATCH, PUT, OPTIONS env=ENV_SET
    Header set Access-Control-Allow-Headers: Origin, Content-Type, X-Auth-Token env=ENV_SET
</IfModule>

Tanto quanto eu entendi que faria os cabeçalhos definidos condicionalmente na existência da variável de ambiente, mas eles estão sendo definidos, não importa o quê. Se eu remover as linhas SetEnvIf, elas ainda estarão definidas. Eu encontrei este que sugere que ele deveria ser colocado na configuração ao invés de .htaccess, mas eu Não tenho certeza do que isso significa.

Alguma sugestão sobre como posso consertar isso ou outra maneira de fazê-lo funcionar?

Obrigado

EDIT: sintaxe atualizada com conselhos do w3dk, agora parece

    SetEnvIfNoCase Origin "%{ENV:proto}://mysite.com" ENV_SET
    SetEnvIfNoCase Origin "%{ENV:proto}://mautic.mysite.com" !ENV_SET
    Header set Access-Control-Allow-Origin "%{ENV:proto}://mysite.com" env=ENV_SET
    Header set Access-Control-Allow-Credentials "true" env=ENV_SET
    Header set Access-Control-Allow-Methods "GET, POST, PATCH, PUT, OPTIONS" env=ENV_SET
    Header set Access-Control-Allow-Headers "Origin, Content-Type, X-Auth-Token" env=ENV_SET

EDIT 2: Acontece que não gosta da parte% {ENV: proto}, então eu mudei para http e adicionei outra linha para https. O subdomínio está funcionando bem e os cabeçalhos estão configurados, exceto que estou recebendo 'O sinalizador Credentials é' true ', mas o cabeçalho' Access-Control-Allow-Credentials 'é' true, true '.' no console. Ele está sendo definido apenas uma vez (eu também tentei 'mesclar', e estou usando o conjunto para o Allow-Origin; não consigo descobrir onde mais isso seria definido.

    
por Elenchus 18.10.2016 / 11:18

1 resposta

0

Header set Access-Control-Allow-Methods: GET, POST, PATCH, PUT, OPTIONS env=ENV_SET

Se o valor contiver espaços, ele deverá ser colocado entre aspas duplas. Provavelmente mais seguro sempre coloque o valor entre aspas. Você também deve omitir o : no final do nome do cabeçalho. Então, por exemplo:

Header set Access-Control-Allow-Methods "GET, POST, PATCH, PUT, OPTIONS" env=ENV_SET
SetEnvIfNoCase Origin %{ENV:proto}://mautic.mysite.com ENV_SET=0

UPDATE: O terceiro argumento para SetEnvIf[NoCase] é um regex, então variáveis do servidor (ex. %{ENV:proto} não são expandidas - elas serão combinadas literalmente. Se você precisa coincidir com http ou https e depois construir isso em um único regex, por exemplo, https? (O ? torna o caractere anterior opcional). (No entanto, seu site deve ser um ou outro, não ambos?)

Para anotar / remover uma variável de ambiente, você deve prefixar com ! (ponto de exclamação) em vez de defini-la como 0 (isso ainda está definido). Por exemplo:

SetEnvIfNoCase Origin https?://mautic.mysite.com !ENV_SET

If I remove the SetEnvIf lines they're still set.

Provavelmente por não ter conseguido citar o cabeçalho valor . Mas isso também pode ser um problema de cache - portanto, verifique se todos os caches estão limpos.

...it should be placed in configuration instead of .htaccess

Por "configuração", eles provavelmente estão se referindo à configuração do servidor . Isso seria preferível (e desabilitar o uso de arquivos .htaccess ). No entanto, não é a causa deste problema.

    
por 18.10.2016 / 12:15