Getting 403's when accessing vendor folder.

[evert]

Urls such as these are getting blocked:

http://katana.azurewebsites.net/static/vendor/event-source-polyfill/eventsource.min.js

And also in the kudu console. Let me know if you need additional info.

To reproduce, you can install (sabre/katana)[http://github.com/fruux/sabre-katana], and:

1. Set the public directory to public/.
2. Also make sure that at least the following are run:

composer install
npm install
bower install --production

[carbontwelve]

I had the same issue which I raised on stack overflow here, ended up wasting a lot of time on it before a college suggested it might be the composer extension adding some form of wild card re-write rule (which it is.)

Within the applicationHost.xdt the rewrite rule that forbids access to the vendor directory needs amending so that it doesn't catch all paths containing vendor in their name, eg it not only blocks /vendor/ but also /js/vendor/some.js,/css/vendor/some.css and /some/long/deep/folder/structure/with/vendor/index.html.

Prepending <clear/> to the rewrite of your web.config file in your www root will clear the rewrite rules set by the extension and fix the issue on a per site basis.

Just for the record the vendor directory of an application should never be inside the www root, for example I have a public folder along side the vendor folder and it is the public folder that is set as my www root, therefore vendor is never navigable from a browser but still accessible for the php app to use.

[andysnell]

After troubleshooting why my frontend fonts were not loading, it appears that this issue and #6 have never been resolved. The side effect of the rewrite rule affecting every vendor directory is unexpected and frustrating. Not being able to verify what is in the vendor file from Kudo is also troubling. Can the rewrite be rewritten to only effect a top level vendor directory? If not, perhaps it should be removed entirely. As @carbontwelve mentioned, the wwwroot is not always the actual root, probably more often than not, and it should be up to the developer to secure the files they want secured.

[SyntaxC4]

should be addressed by #20