Migração da regra de Cabeçalho de Autorização do Apache para o Lighttpd

1

Meu servidor web está executando aplicativos PHP com lighttpd e PHP-FPM por anos. Agora, depois de uma atualização de software de terceiros, devo incluir algumas regras para ativar uma API REST.

<IfModule mod_setenvif.c>
  SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0
</IfModule>
<IfModule mod_rewrite.c>
  Options -MultiViews
  RewriteEngine On
  RewriteBase /api/
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule .* index.php [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
</IfModule>

Eu gostaria de entender o que está fazendo e reescrevê-lo com base na configuração do lighttpd se ele tiver o suporte.

    
por LeonanCarvalho 26.09.2017 / 15:26

2 respostas

1

A configuração da variável de ambiente HTTP_AUTHORIZATION ("CGI") deve acontecer como parte da configuração CGI (os cabeçalhos são passados como HTTP_... ), e o lighttpd NÃO exclui o cabeçalho "Authorization", então nada para fazer aqui no lighttpd.

A configuração de reconfiguração reescreve todas as solicitações que não segmentam arquivos ou diretórios estáticos no subcaminho /api/ . O mais próximo em lighttpd ( 1.4.24+ ) sem usar mod_magnet seria:

url.rewrite-if-not-file = ( "^/api/" => "/api/index.php" )

Isso também irá disparar para diretórios (somente arquivos regulares não são reescritos), mas eu acho que é improvável que você realmente precise de dirlistings dentro do caminho /api/ , então provavelmente está bem.

    
por 01.10.2017 / 10:17
1

I would like to understand what is it doing

  1. Define uma variável de ambiente chamada HTTP_AUTHORIZATION para o valor do cabeçalho da solicitação Authorization HTTP (se houver). Isso pode não ser necessário na configuração do seu servidor. O PHP deve definir isso automaticamente, no entanto, dependendo de como o PHP está instalado em algumas configurações do Apache, isso não acontece - daí este pedaço de código. (Observe que o código acima tenta definir isso de duas maneiras diferentes - mas o resultado líquido é "quase" o mesmo).

  2. Front controller - Todos os pedidos que não mapeiam para arquivos existentes (ou diretórios) são reescritos internamente em /api/index.php . Este é um "padrão de controlador frontal" padrão.

Então, basicamente, o código acima é apenas um front-controller padrão que direciona todos os pedidos para /api/index.php .

and rewrite it based on lighttpd configuration

Infelizmente, não falo o lighttpd, mas pesquisando lighttpd front controller obtém algumas possibilidades. Por exemplo, desta página , desde que os módulos necessários estejam habilitados, eles sugerem que você pode fazer algo como:

url.rewrite-once = ( "^/(.*)\.(.*)" => "$0", "^/([^.]+)$" => "/index.php", "^/$" => "/index.php" )

Embora isso não pareça realmente verificar a existência de um arquivo solicitado, mas pressupõe que os pedidos de arquivos terão uma extensão de arquivo (minha interpretação).

    
por 26.09.2017 / 22:06