The webroot folder can have any name - a folder needs to be designated, I thought the spec was pretty clear on this point? :-)
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+unsubscribe@googlegroups.com.
To post to this group, send email to php...@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+unsubscribe@googlegroups.com.
To post to this group, send email to php...@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.
Hi,
It seems easier to discuss here.
Since this standard focus on publishing client-side assets. I think, assets pipeline and directory structure are out of scope for this standard.
I also commented the gist (https://gist.github.com/mindplay-dk/90507eb164e74bac7bbbf9abc97a04ee#gistcomment-1899260).
> 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.
Using this standard, people can know what packages you are using because of its predictable paths. Some packages are running server-side code as well as exposing public assets.
I said (in the comments of the gist) that exposing stuff is the responsibility of the developer. I’m sure some people will be confused and disclose informations they shouldn’t (as mention by Fabien).
A lot of people do a lot of things wrong. In my opinion, it's better to create simple things that are easy to learn to use correctly - as opposed to creating complex things that supposedly shield you from making mistakes. Often such things provide only a false sense of security - and usually you can break them and hurt yourself anyhow.
Most server side components have some kind of client side footprint - URLs or HTML class names etc which can be used to figure out what you're running.
I really don't think it's within the scope of this specification to teach OWASP 101? Package names are obviously revealed in the URLs - it's hardly a hidden detail, it's basically the whole concept.
In my opinion, there is no security problem inherent in this idea, unless you create one.
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/c2ba50bb-ad74-4675-8ccd-08cdd8a360a0%40googlegroups.com.
A lot of people do a lot of things wrong. In my opinion, it's better to create simple things that are easy to learn to use correctly - as opposed to creating complex things that supposedly shield you from making mistakes. Often such things provide only a false sense of security - and usually you can break them and hurt yourself anyhow.
Most server side components have some kind of client side footprint - URLs or HTML class names etc which can be used to figure out what you're running.
I really don't think it's within the scope of this specification to teach OWASP 101? Package names are obviously revealed in the URLs - it's hardly a hidden detail, it's basically the whole concept.
In my opinion, there is no security problem inherent in this idea, unless you create one.
On Oct 17, 2016 9:30 PM, "Sven Sauleau" <sven.s...@gmail.com> wrote:
--Using this standard, people can know what packages you are using because of its predictable paths. Some packages are running server-side code as well as exposing public assets.
I said (in the comments of the gist) that exposing stuff is the responsibility of the developer. I’m sure some people will be confused and disclose informations they shouldn’t (as mention by Fabien).
Le lundi 17 octobre 2016 16:43:25 UTC+9, Rasmus Schultz a écrit :I wrote a draft for a simple scheme for the inclusion of static assets in (Composer) packages.Not submitting this or anything, just dumping it here to start a discussion :-)Thoughts?
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+u...@googlegroups.com.
Ugh I didn’t say that :( What I said with more emphasis:
Not because of all its features,
(because I agree Puli is very complex)
but because it contains a very simple solution to a wider problem: locating resources.
(“contains” ≠ “is”)
You want to standardize a assets/
directory, I’m suggesting to standardize the res/
directory instead (which would contain assets).
And it’s not more complex, I would argue it’s even simpler because instead of creating discrepancies between different resources (assets, templates, config…) it would all have the same behavior.
The problem is, I don’t have any of those requirements - so it solves a bunch of problems that I don’t have.
What people do with assets is a real question. Either the PSR addresses the major use cases, or it avoids addressing any (both solutions are good but the last one is obviously simpler).
Matthieu
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_jMYt_fM7Fk2JbFYwTsf%2B6LJR-0ykmwKi9gnCXjWT2A5g%40mail.gmail.com.