Implement custom importers

[pistolero]

I would like to use libsass with user-generated SCSS templates, but exposing libsass to user creates security threat. By crafting @import directives users can read some, possibly sensitive files, for server filesystem.

I would be nice if libsass would have support for custom importers, and have control over access to filesystem.

[Igorbek]

I also agree with the issue. It would be great to have some interface that implement custom importers.

[Igorbek]

I have implemented this functionality in my fork: https://github.com/Igorbek/libsass/tree/SourceProvider

[pistolero]

Wow, that is fantastic

[Igorbek]

@pistolero http://habrahabr.ru/post/147567/ =)

[pistolero]

@Igorbek nice. Do you plan to send pull request with your changes to @hcatlin for review?

[Igorbek]

@pistolero yep, I'll do it today after take some code cleaning.

[jhnns]

Is this feature still planned? I could need it too 😄

[HamptonMakes]

I believe this is already solved. Please let me know if it's still an issue.

[BPScott]

Hi @hcatlin, I've had a look through the source code and while I've found code to allow adding a vector of custom include paths, I haven't spotted the ability for tools that bind to libsass (e.g. node-sass) to provide a custom @import resolver. Could you point me to where I could find that?

The use-case I'm thinking of is that binding libraries could provide hooks into that ecosystem's package manager. For instance node-sass could provide an @import resolver that transverses npm's node_modules folder. This is would be similar to Rework providing an npm loader. In the same vein, the ruby bindings could provide a resolver to transverse the rubygems folder structure.

Thanks.

[jhnns]

@BPScott that's exactly the use-case 👍

[HamptonMakes]

Hmm... yeah, we haven't written anything like that. I bet we could do it
with a callback that you can register.

In your mind, would you expect the @import callback to act like a "last
ditch" or "method missing" resolver? Or, have it be the first thing
called, and then if it's unaware of a package name, go to the standard Sass
import resolver?

On Mon, Oct 6, 2014 at 10:36 AM, Johannes Ewald notifications@github.com
wrote:

@BPScott https://github.com/BPScott that's exactly the use-case [image:
👍]

Reply to this email directly or view it on GitHub
#21 (comment).

[BPScott]

I think it would need to be the first thing to try. This functionality feels like an override rather than a fallback coping mechanism.

I believe @import 'foo/bar; would need to look within the foo package first, then if that fails it should use the default resolver to try the relative file path ./foo/bar.scss (though it could be up to the binding library to skip trying the default resolver). Otherwise you could end up with oddness where files relative to the current file take precedence over the files from the package manager which would be undesirable.