I'm not saying that we should not do it (and in fact, we are doing
something similar in Symfony), just that we should mention this
somewhere. It's important to mention any potential security issue (even
if it is small) so that developers can take a conscious decision.
On 10/17/16 11:21, Rasmus Schultz wrote:
Er, but, even if you mangled the filenames, all anyone would need to
do is checksum the contents of the files, and they'd known which
vendor libraries you're using, like, immediately.
There are blatantly simple ways to sniff most popular client and
server-side libraries. Hiding package names amounts to nothing more
than security by obscurity.
If you don't trust the packages you're using, or don't trust the
people using it, IMHO, you have much bigger (unrelated) problems...
On Mon, Oct 17, 2016 at 5:13 PM, Fabien Potencier
<fabien.potenc...@gmail.com> wrote:
On 10/17/16 07:54, Rasmus Schultz wrote:
Having a direct correlation between the asset paths and the package names
means that you are leaking some interesting/"sensitive" information for a
potential hacker.
How so?
If assets are under twigphp/twig or symfony/symfony, it gives information
about which stack I'm using. I'm not saying that per se, this is enough, but
it gives some interesting hints.
The only way I can see your vendor/package name as "sensitive
information", is if you have a very serious security problem somewhere
else - otherwise, exposing the vendor/package-name should not be a
concern. It's a name. It means nothing unless you exposed the vendor
folder to the public or something - in which case the problem wasn't
created here and shouldn't affect the design, IMO.
On Mon, Oct 17, 2016 at 4:11 PM, Fabien Potencier
<fabien.potenc...@gmail.com> wrote:
On 10/17/16 00:12, Rasmus Schultz wrote:
Why do you want the folder name to be named assets itself ?
The folder has to have a name - "assets" seemed like the logical choice.
Perhaps what you're really wondering is, why a single folder and not a
map like in the Aura library?
Because it's simpler. A map would require more than a standard - it
would require at least a configuration file format specification,
and/or possible a library or interfaces.
Also, because we learned from doing something similar at work, that
being able to symlink vendored asset folders into the project's public
asset folder is really useful - it enables you to run an installation
script once, and the continue to add more files to the vendor
packages, since every file in the symlinked folder becomes
automatically available.
Another reason is that a map cannot be interpreted or resolved at
design-time, by the browser - things like source-maps of relative
paths fall apart, since the relative public URLs do not map directly
to physical files. This is perhaps the main reason we came up with
this approach - anything else has proven to be highly impractical to
work with. Having to run a build or deploy script between every change
is cumbersome.
Finally, the length or appearance of asset URLs is typically
completely irrelevant - about as irrelevant as the physical
file-system structure is to Composer packages. For the most part, no
person will ever see the URL of your CSS or JS files - wanting shorter
or neater URLs is purely vanity, it has no practical consequence.
Having a simple, predictable URL structure that prevents collissions,
is much more valuable than having pretty URLs.
I disagree. I agree that nobody cares about the FS structure of the
Composer
packages; but for assets, that's a bit different, security wise. Having a
direct correlation between the asset paths and the package names means
that
you are leaking some interesting/"sensitive" information for a potential
hacker.
Fabien
Good question though, thanks for reviewing this :-)
On Mon, Oct 17, 2016 at 3:00 AM, Hari K T <kthar...@gmail.com> wrote:
Thank you Rasmus Schultz for the nice write up.
After looking at it I think, it was something similar to what we had
for
Aura https://github.com/friendsofaura/Aura.Asset_Bundle .
I recently added psr-7 support : https://github.com/harikt/psr7-asset (
Not
saying it is perfect )
I like some of the good things you mentioned towards the end of "A
component
responsible for the delivery of vendor-supplied assets:"
https://gist.github.com/mindplay-dk/90507eb164e74bac7bbbf9abc97a04ee#12-asset-url-scheme
Also I have question :
Why do you want the folder name to be named assets itself ? ( But I do
agree
it is good to have a folder not to expose other files ;-) )
What Aura.Asset_Bundle was using was mapping the folder with the
package
path. So it don't necessary to be in vendor folder you mentioned. It
gives
flexibility for the users to choose the path for their vendor specific
css.
Eg : In our case you can alter the css / js behaviours of the
vendor/a/b
with your own if you are mapping to /web/project-specific-assets .
I do understand it needs some configuration though.
And thanks for bringing this up, and it will be nice feature to have
for
considering psr-7, psr-15 etc.
Thank you
Hari K T
You can ring me : +91 9388 75 8821
http://harikt.com , https://github.com/harikt ,
http://www.linkedin.com/in/harikt , http://www.xing.com/profile/Hari_KT
Skype : kthari85
Twitter : harikt
On Mon, Oct 17, 2016 at 3:10 AM, Rasmus Schultz <ras...@mindplay.dk>
wrote:
The webroot folder can have any name - a folder needs to be
designated,
I
thought the spec was pretty clear on this point? :-)
On Oct 16, 2016 23:00, "Christopher Pitt" <cgp...@gmail.com> wrote:
Nice write-up. Do you think it would be possible to survey member
projects (including recently departed projects, like Laravel), to
determine
things like the most common/preferred name for the webroot folder?
--
You received this message because you are subscribed to a topic in
the
Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/php-fig/f4qtsS54mVY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/ad00f8f7-74f3-4a00-99aa-8b0909df7fa9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups
"PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/CADqTB_gt7%2BjPbRKUZ88-m%2Be3N1OanuC%3DOiMj2QNZ%3DfkqjtmDqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the
Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/php-fig/f4qtsS54mVY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/CAESZFtK_vrVRKEVFHBENU2hdFxGEc8P%2Bk4HL2m2F3sB2PHRymg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the
Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/php-fig/f4qtsS54mVY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/05c76270-d682-7f65-d611-f37af67c1a8a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the
Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/php-fig/f4qtsS54mVY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/9b8ba3b5-bfa3-72e1-7270-17fdad9ab73c%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/e0f5ad63-826e-46b8-77a3-8ce2fa0b2d98%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
