Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unminified assets remain accessible #65

Open
ejain opened this issue Jul 1, 2014 · 13 comments
Open

Unminified assets remain accessible #65

ejain opened this issue Jul 1, 2014 · 13 comments

Comments

@ejain
Copy link

ejain commented Jul 1, 2014

The .less files and unminified js files can be retrieved by anyone who cares to guess the URLs for these assets!

@rkrzewski
Copy link

When original sources and source maps are present in the production build of the application, you are able to debug the actual version deployed to production. You might want to restrict access to those files to a corporate network / VPN using front-end Apache or Varnish but that's a whole another story.

It can be also argued that obfuscating your JS code does not make the application any more secure ;)

@ejain
Copy link
Author

ejain commented Jul 2, 2014

Obfuscation may not protect your secret sauce algorithm, but most people probably don't want to have their full source code including comments etc exposed, at least not by default and by surprise! btw the original sources are still present even when the generation of source maps is disabled.

@dylemma
Copy link

dylemma commented Jul 6, 2014

👍 It would be nice if this functionality could be turned on/off by a setting somewhere.

@benmccann
Copy link
Contributor

Fixed this for sbt-rjs and am just awaiting a new release for that plugin. Still need a solution for sbt-less though

@huntc
Copy link
Contributor

huntc commented Jul 7, 2014

@benmccann This problem will be resolved via sbt-web as a whole, relating to this particular issue.

@mariussoutier
Copy link

This also applies to WebJars. A lot of files are generated only to map them to a CDN at runtime. A single file in a WebJar results in six files after the assets pipeline is run.

For example the webjars-requirejs contained in nearly every WebJar:

webjars-requirejs.js.gz
webjars-requirejs.js.map
webjars-requirejs.js.map.md5
webjars-requirejs.js.md5
webjars-requirejs.js.src.js.gz
webjars-requirejs.js.src.js.md5

@huntc
Copy link
Contributor

huntc commented Jul 25, 2014

@ejain Can you report back as to whether https://github.com/rgcottrell/sbt-filter fixes this issue to your satisfaction?

@mariussoutier I would think that the above filter should filter WebJar contributed assets also (unless it avoids the lib folder explicitly). The pipeline sees all assets including WebJar contained ones.

@mariussoutier
Copy link

@huntc Unfortunately the plugin ignores the lib folder.

I'm also encountering an issue with sbt-digest. When I'm filtering out all js, but keeping the digest main.js (via excludeFilter in filter := "*-main.js"), the Assets controller fails to find the main script, even though the Play assets jar does contain it.

@strelec
Copy link

strelec commented Feb 11, 2015

So? What's the progress like on this?

@huntc
Copy link
Contributor

huntc commented Feb 11, 2015

@pvlugter Do you know if this is still an issue?

@ejain
Copy link
Author

ejain commented Feb 11, 2015

@huntc it's still an issue in Play 2.3.7. The sbt-filter solution works for me, but shouldn't this be done by default?

@huntc
Copy link
Contributor

huntc commented Feb 11, 2015

@ejain If you could check that you're using the latest version of all sbt-web related plugins then that'd be great. sbt-web plugins have a release cycle that is different to Play's.

@ejain
Copy link
Author

ejain commented Feb 11, 2015

@huntc yes, my sbt-web plugins are all up to date. btw the plugins.sbt created with activator new references way outdated versions of the plugins...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants