Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I have an issue. I have implemented a custom stream wrapper using hook_file_stream_wrappers. The CDN module doesn't respect my custom stream wrapper and always puts the CDN url in front of my uri. This is an issue because my files are behind an access control system and I need the option to add the cdn url or not too. Would it be possible to add a hook of respected stream wrappers?
Comment | File | Size | Author |
---|---|---|---|
#8 | custom_stream_wrappers-1863310-8.patch | 815 bytes | Wim Leers |
Comments
Comment #1
Wim LeersHm.
So you have some kind of custom scheme, such as "myscheme" instead of "public" or "http" or "https"? Or are you just using Drupal's "private files" support?
Does the CDN module currently successfully serve these files from the CDN?
Comment #2
pwaterz CreditAttribution: pwaterz commentedThanks for your response!
Yes I am using my own custom scheme hwfilestream:\\, yes it does successfully server the file. But I have custom logic in my stream wrapper class that I want to be able to say server from the CDN or not to server from the CDN, but I have no way of stopping the CDN module from sticking the origin pull domain in from of the url. Even if i return a full url, including http:\\ from my class, it still puts the cdn domain in front of it.
I just noticed in cdn.module on line 93 you have
Which essentially just ignores a stream wrapper the returns a full path. I dont think CDN module should hijack all stream wrappers. Only stream wrappers that return relative urls.
Comment #3
Wim Leers#2: that's a sharp, excellent observation! However, if memory serves me well, that is unfortunately an absolute necessity, because Drupal's default "public://" stream wrapper in fact always returns absolute URLs…
Comment #4
pwaterz CreditAttribution: pwaterz commentedhmm....going to have to think about this one :)
Comment #5
pwaterz CreditAttribution: pwaterz commentedIt almost seems like there should be a setting for enabled or disable stream wrappers. If that the point of stream wrappers to be able to differentiate different collections of files.
Comment #6
Wim LeersI think you're the first one to use streamwrappers that are not the built-in "public://" or "private://" ones :)
AFAICT, you're right. The only thing I can think of that can help solve this, is checking the file URL being altered against a list of allowed schemes. The default list should include 'http', 'https' and 'public'. It should exclude 'private'. You could then also exclude 'hwfilestream'. We must use http://api.drupal.org/api/drupal/includes%21file.inc/function/file_get_s... for that.
One note: is 'hwfilestream' marked as a local or remote stream wrapper? If it's the latter, we may want to consider using that distinction instead.
P.S.: cool, you're from Palo Alto! :) I was there last year for an internship :)
Comment #7
pwaterz CreditAttribution: pwaterz commentedHmm..i think checking the local flag is a good idea. That way you dont need to have a settings page and other stream wrappers can control weather or not the cdn is invoked. Ill try and work up a patch in the next few days.
Nice, PA is great! We are looking for people if your interested!
Comment #8
Wim Leers#7: Hah, thanks :) I declined a job at Facebook already precisely because I don't want to emigrate from Belgium, so… I'm going to have to respectfully decline again :) Thanks though!
Comment #9
pwaterz CreditAttribution: pwaterz commentedHaha worth a try, always looking for some good talent! Patch looks good by the way!
Comment #10
mermentau CreditAttribution: mermentau commentedThe patch works for me on Amazon S3 content.
Comment #11
Wim LeersGreat, thanks! :)
Comment #12
Wim Leers(This is on the edge of feature request vs. bug report.)
Thanks to the feedback in #10: committed!
http://drupalcode.org/project/cdn.git/commit/31b46c6