Serve collections without serve single files

[chrvadala]

Hi,
I'm using AssetManager with a collection resolver, but I think there is a security issue.

I have a situation like this

   'resolver_configs' => array(
        'collections' => array(
            'css/style.css' => array(
                'css/lessfile1.css',
                'css/lessfile2.css',
            ),
           ),

        'paths' => array(
            __DIR__ . '/../public',
        ),
    ),

       'filters' => array(
        'css/style.css' => array(
            array(
                'filter' => 'Lessphp',
            ),
        ),

This works correctly. I can see /css/style.css correctly. The security problem is related to paths. To use a collection I need to configure a path that expose my single files.
I want to serve only files merged and compressed, because in single files there are a lot of team's comments.

An easy solution could be like this:

     'resolver_configs' => array(
        'collections' => array(
            'css/style.css' => array(
                  __DIR__ . '/../public/css/lessfile1.css',
                  __DIR__ . '/../public/css/lessfile2.css',
            ),
           ),
    ),

       'filters' => array(
        'css/style.css' => array(
            array(
                'filter' => 'Lessphp',
            ),
        ),

But this doesn't work because I think that a collection expect an alias and not a path. Is there another solution?

[Ocramius]

@work-out-web you can simply configure a MapResolver instead of a path stack resolver.

[chrvadala]

I think that it's the same thing. If I use a MapResolver all single files are however exposed in public.

I want that nobody can access from an url like this http://www.example.com/css/lessfile1.css

[RWOverdijk]

@work-out-web I see your problem. It's not a "risk", it's just too much freedom; and you're right. What we could do is add a config key for restrictions (essentially blacklisting or whitelisting assets; for internal or external use).

Is this a big problem to you?

[Ocramius]

Ah, I see the problem. I don't think it's a security concern though.

[chrvadala]

@RWOverdijk I think that add a whitelist can be an extra work. In my opinion add a method to specify a full path in collections is the easist way to solve this problem and also avoiding BC.

 'css/style.css' => array(
    __DIR__ . '/../public/css/lessfile1.css',
    __DIR__ . '/../public/css/lessfile2.css',
    '/css/aliasfile.css'
),

@Ocramius
You're right but I think that expose files with a lot of team's comment can sometime be risky.
Not a serious risk, but still a risk. :D

[RWOverdijk]

@work-out-web We don't want to avoid BC, we want to avoid BC-breaks. If we add white/black-listing it has to be for dirs, paths, and aliases. While on that, we might as well add the possibility to add existing files to collections (without re-resolving them). This sounds like a nice update to me, personally. Can you work out a proposal?

@Ocramius What are your thoughts on this?

[Ocramius]

@work-out-web mapping assets means the assets are available, and that must be clear to the developer.
Also, we're really just talking about assets. I don't think it's a security issue.

This is an overkill in my opinion, and requires a lot of rewrites and probably isn't even compatible with the current architecture.

I'd just suggest to mark it as "won't fix", since the benefit is near to 0, especially compared to the effort required to implement this.

[chrvadala]

@RWOverdijk Your idea is not simply to realize, ad I accord with @Ocramius that it require a lot of rewrites.

Effectly my idea goes against this principle "mapping assets means the assets are available, and that must be clear to the developer" and this is bad.

I'm going to solve my problem with a custom resolver.
I hope however that this discussion has brought out an interesting point to be explored.

[RWOverdijk]

I guess it has. Though we actually bundle our assets ourselves, and prefer them to be accessible to the public (in case we need a file for a specific component on a completely different page).

[Thinkscape]

Meh, this just hit me in the face.

The way I usually work with asset collections (see assetic and node.js stuff) is that collections might be accessible in debug mode (devel mode). However, by default, individual files must not be accessible. I'd also call it a security risk - I had no idea that creating a collection exposes my files... so it doesn't fulfill the "clear to the developer" requirement.

What should be accessible is the collection itself and nothing more.

If I wanted individual files to be accessible, I'd expect one of the following:

• I'd just us path/map resolver together with collection resolver, or
• I'd use some special flag/option in collection resolver, i.e. expose_individual_files => true.

The above promotes explicitness and brevity.

[Thinkscape]

I see the problem in architecture... collection resolver is an aggregate, so it is able to use other resolvers for stackability. That's actually quite cool, but is source of the problem here.

One of the ways to solve this is to have a separate (private) resolver aggregate for collections. Other idea is to have 2 user-defined stacks for resolvers - i.e. public and private. The former would be used for MVC, while the latter would be used for aggregates. Whatcha think ?

[Ocramius]

The idea is good, but it sounds like the implementation will be a hack...

[Thinkscape]

Another idea is separation of production and devel by moving out "compilation" (merging, filtering) outside of the standard asset serving.

The standard workflow (for most websites) is:

1. devel : fiddling with tens source files, lessc/sass, images, js/coffee, require.js (or other AMD) because it helps with debugging.
2. deploy : files get grouped, merged and minified.
3. production : we get just a handful of compiled sprite/css/js files that are put into public/ or uploaded to CDN. Source files stay outside of webroot (i.e. in module/*/assets)

I've played with the module for a few hours but dumped it in favor of zf2-assetic-module because I could not easily do the above :\

[RWOverdijk]

It's not a big deal. If you want to serve combined files without exposing the individual files, add a compile step (as you really should). But, I see that not everyone does this. So it's probably an idea to add something for those people. (I don't really want to, as it goes against what I believe is the way of serving assets, but clearly there's need for it).

So how about this:

• We add support for directly addressing files in collections. We'll add a resolver to the stack, being filePathResolver which will simply check if the file exists. Like this, you won't need the map.
• We'll add simple acl. You can then by default specify the resource is available internal or public. To make this easy, we'll allow for it to be sent along with the config in the map / path / whatever alias you've used.

I'd say, let's implement both. The latter has the added benefit of less resolving, as we can already exclude files based on these rules.

[Thinkscape]

@RWOverdijk you're missing my point mate.

Acl is a terrible idea... Compilation is part of the asset management. Why would you use jsmin filter with AssetManager in development ?

The primary problem with this module is that it does not allow to clearly divide between production and development. Right now, in order to have compilation I'd have to use separate module, write my own or have separate sets of configs for assetmanager (which still wouldn't work as expected).

Here are the things that are missing:

• Production means compilation.
• Devel shouldn't use compilation or compiled versions of files.
• I want to define my assets once and then use them in both production and devel.
• I want helpers to expand collections in devel, so devel uses individual unminified files.
• I want helpers to use minified files in production, so production uses big monolitic optimized files.
• Individual files, that have been compiled (or has not been moved), must not be visible in production.