[bd] Attachment Store [Deleted]

@xfrocks Got this email from Amazon, maybe something we can use with this addon?

Dear Amazon CloudFront Customer,

We're excited to let you know that we've added two new features that allow to you to configure how CloudFront handles error responses for your website. Error responses can occur for many reasons. For instance, a user might request objects that don't exist (and receive a 404 Not Found response) or a user you haven't authorized might attempt to download an object you have secured using CloudFront's private content feature (and receive a 403 Forbidden response). Previously, CloudFront would respond with a standard HTML page that would be cached for 5 minutes. These two new features provide you with more control over error responses:

  • Custom Error Pages allow you to serve error pages with your own branding and content. For example, you can now help your visitors navigate to other sections of your website when they request an invalid URL, or you can configure a static page to serve as a fallback for failure of an origin webserver.
  • Configurable Cache Duration for Error Responses allows you to specify how long you want each error page to be cached at CloudFront edge locations. Previously, error responses were cached for five minutes. With the introduction of this feature, you can now choose how long you would like to cache error responses and how frequently CloudFront checks with your origin after an error.
Getting started with these features is easy - just visit the CloudFront developer guide to learn more about Custom Error Pages and Configurable Cache Duration for Error Responses. There is no additional fee to use these features - you continue to pay our existing low data transfer and request rates for your use of CloudFront.


Sincerely,
The Amazon CloudFront Team
 
@xfrocks Got this email from Amazon, maybe something we can use with this addon?

Dear Amazon CloudFront Customer,

We're excited to let you know that we've added two new features that allow to you to configure how CloudFront handles error responses for your website. Error responses can occur for many reasons. For instance, a user might request objects that don't exist (and receive a 404 Not Found response) or a user you haven't authorized might attempt to download an object you have secured using CloudFront's private content feature (and receive a 403 Forbidden response). Previously, CloudFront would respond with a standard HTML page that would be cached for 5 minutes. These two new features provide you with more control over error responses:

  • Custom Error Pages allow you to serve error pages with your own branding and content. For example, you can now help your visitors navigate to other sections of your website when they request an invalid URL, or you can configure a static page to serve as a fallback for failure of an origin webserver.
  • Configurable Cache Duration for Error Responses allows you to specify how long you want each error page to be cached at CloudFront edge locations. Previously, error responses were cached for five minutes. With the introduction of this feature, you can now choose how long you would like to cache error responses and how frequently CloudFront checks with your origin after an error.
Getting started with these features is easy - just visit the CloudFront developer guide to learn more about Custom Error Pages and Configurable Cache Duration for Error Responses. There is no additional fee to use these features - you continue to pay our existing low data transfer and request rates for your use of CloudFront.


Sincerely,
The Amazon CloudFront Team
Wondering why I haven't receive that email. Anyway, the features sound nice but I haven't had any ideas yet.
 
Hi @xfrocks
About the permission check. Let's say my CDN is cdn.domain.com (CNAME).
When I try to navigate to any attachment on my website through the cdn.domain.com, it asks for username/password since it recognizes it as a different domain/sub-domain and doesn't save the cookie from the original domain. Then how the CDN provider knows to cache these permission protected attachments (the provider is accessing the website as a gust).

I'm using CDN.NET if that makes any difference.
Thanks.
 
Hi @xfrocks
About the permission check. Let's say my CDN is cdn.domain.com (CNAME).
When I try to navigate to any attachment on my website through the cdn.domain.com, it asks for username/password since it recognizes it as a different domain/sub-domain and doesn't save the cookie from the original domain. Then how the CDN provider knows to cache these permission protected attachments (the provider is accessing the website as a gust).

I'm using CDN.NET if that makes any difference.
Thanks.
With permission check enabled, the attachemnt will go to domain.com/attachments/1 to check for permisison first then user will be redirected (if permission check is okie) to cdn.domain.com/path/to/the/actual/file.ext to download the file.
 
With permission check enabled, the attachemnt will go to domain.com/attachments/1 to check for permisison first then user will be redirected (if permission check is okie) to cdn.domain.com/path/to/the/actual/file.ext to download the file.
Let's say I have an attachment at: domain.com/attachemnts/1
And I'm logged in and can view this attachment. Then, when I try to navigate to cdn.domain.com/attachemnt/1
I get a login screen. The fact that I get a login screen is what concerns me. Should I worry?
I didn't really understand this:
cdn.domain.com/path/to/the/actual/file.ext

I get the idea that the actual link to the attachment isn't /attachment/1 but something like data/attachments/###/#/whatever
 
Last edited:
Let's say I have an attachment at: domain.com/attachemnts/1
And I'm logged in and can view this attachment. Then, when I try to navigate to cdn.domain.com/attachemnt/1
I get a login screen. The fact that I get a login screen is what concerns me. Should I worry?
I didn't really understand this:
cdn.domain.com/path/to/the/actual/file.ext

I get the idea that the actual link to the attachment isn't /attachment/1 but something like data/attachments/###/#/whatever
When you use this addon, it will not ask for password when you go to the cdn link.
 
When you use this addon, it will not ask for password when you go to the cdn link.
Well, I'm using this add-on and it does ask for username/password. Even navigating to cdn.mydomain.com asks to re-connect to the website since it doesn't save cookie (the browser detects it as a sub-domain, so you need to reconnect).
 
Well, I'm using this add-on and it does ask for username/password. Even navigating to cdn.mydomain.com asks to re-connect to the website since it doesn't save cookie (the browser detects it as a sub-domain, so you need to reconnect).
Which working mode are you using?
 
For that mode, the url should be cdn.domain.com/data/attachment-files/... , not cdn.domain.com/attachments/..., please confirm?

Do you happen to use the add-on[Tinhte] Image Attachment Optimization & CDN Support?
I'm not using Tinhte's add-on since it doesn't enforce permissions.
I'm a little bit confused. When I right click on a picture, then "copy image URL", I get
www.mydomain.com/attachments/12760/

Do I need to get
cdn.mydomain.com/attachemtns/12760/?

If yes, what am I doing wrong? I did "Rebuild Attachment Data Storage", and I've configured this in my config.php:
$config['javaScriptUrl'] = 'http://cdn.mydomain.com/js';
$config['externalDataUrl'] = 'http://cdn.mydomain.com/data';

Anything else I'm missing?
 
I'm not using Tinhte's add-on since it doesn't enforce permissions.
I'm a little bit confused. When I right click on a picture, then "copy image URL", I get
www.mydomain.com/attachments/12760/

Do I need to get
cdn.mydomain.com/attachemtns/12760/?

If yes, what am I doing wrong? I did "Rebuild Attachment Data Storage", and I've configured this in my config.php:
$config['javaScriptUrl'] = 'http://cdn.mydomain.com/js';
$config['externalDataUrl'] = 'http://cdn.mydomain.com/data';

Anything else I'm missing?
If you get www.mydomain.com/attachments/12760/ then it's working correctly. User will go to www.mydomain.com for permission check etc before getting redirected to cdn.mydomain.com to actually download the file.
 
If I go to: www.mydomain.com/attachments/12760/ and I'm logged in, then it's working correctly.
If I'm trying to view www.mydomain.com/attachments/12760/
or
cdn.mydomain.com/attachments/12760/

as a guest, it asks for username/password (since attachments on my website are visible for registered users only).

So my overall question is, how CDN.NET caches the attachments if it's for registered users only?
Should I open the attachments for everybody?

Where did you get the URL cdn.mydomain.com/attachments/12760/?
 
Well, if cdn.mydomain.com navigates to mydomain.com, then why wouldn't that work with /attachments/#/
?
You meant going to cdn.mydomain.com will be redirected? That probably be done by .htaccess or similar. The CDN doesn't do that themselves.

Again, where did you get the URL cdn.mydomain.com/attachments/12760/?
 
I was just navigating there. It doesn't work by .htaccess, it works by the control panel of the CDN itself.
Navigating to
cdn.mydomain.com/attachments/12760/
Shows me the image if I log in.
 
Top Bottom