J'essaie de mettre en place un reverse proxy nginx pour le stockage de blobs Azure. J'utilise le nginx:1.13.9-alpine et j'ai un proxy_pass simple configuré comme ceci :
location /container {
proxy_pass https://account.blob.core.windows.net/container;
proxy_set_header Host account.blob.core.windows.net
}Cependant, cela ne fonctionne pas tout à fait. Une demande directe au compte de stockage fonctionne, donc je sais que le jeton SAS est bon :
curl -v "https://account.blob.core.windows.net/container/file?st=2018-04-02T01%3A57%3A00Z&se=2018-04-11T01%3A57%3A00Z&sp=rl&sv=2015-12-11&sr=b&sig=<sig>"Mais l'utilisation du même jeton via le proxy renvoie toujours un 403 :
curl -v "https://proxy.mydomain.com/container/file?st=2018-04-02T01%3A57%3A00Z&se=2018-04-11T01%3A57%3A00Z&sp=rl&sv=2015-12-11&sr=b&sig=<sig>"
...snip...
< HTTP/1.1 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.Dans les journaux du serveur, je vois juste :
10.240.0.4 - - [06/Apr/2018:04:07:30 +0000] "GET /container/file?st=2018-04-02T01%3A57%3A00Z&se=2018-04-11T01%3A57%3A00Z&sp=rl&sv=2015-12-11&sr=b&sig=<sig> HTTP/1.1" 403 621 "-" "curl/7.54.0" "-"J'ai vu des conseils contradictoires sur la nécessité d'inclure $is_args etc., mais rien de tout cela ne semble fonctionner. La même instance de nginx envoie par proxy plusieurs autres ressources par d'autres chemins, qui fonctionnent tous comme prévu. Que me manque-t-il ?
edit
Je pense que cela est lié à des caractères codés tels que %2f dans le chemin de l'URL. Dans ce cas, Azure Storage est utilisé comme backend pour un registre Docker, et il aime donner aux blobs des noms comme %2fdocker/registry/v2/blobs/sha256/e7/e7c1ef..ced394/data . Si j'ajoute un blob d'échantillon dans le conteneur sans l'élément de tête %2f tout fonctionne comme prévu.
