I have a website under Cloudflare CDN. On the other hand, I have a Microsoft blob storage configured as private where I have some images and videos.
I need to config that blob to serve only that media to my website and prevent all other accesses. so for example :
https://test.blob.core.windows.net/1.jpg
should be accessible just from mydomin.com.
can anyone help me?
Thanks
You can make use of CORS for your blob if you wish to prevent access with different domains.
In your storage account -> under setting resource sharing (CORS)
<Cors>
<CorsRule>
<AllowedOrigins>http://*.contoso.com</AllowedOrigins>
<AllowedMethods>PUT,GET</AllowedMethods>
<AllowedHeaders>x-ms-meta-data*,x-ms-meta-target*,x-ms-meta-abc</AllowedHeaders>
<ExposedHeaders>x-ms-meta-*</ExposedHeaders>
<MaxAgeInSeconds>200</MaxAgeInSeconds>
</CorsRule>
<Cors>
CORS provides a secure way to allow one domain you can enable CORS for each service. To enable CORS, you need to set the appropriate service properties using version 2013-08-15
Once you've established the CORS rules for the service then, authorized request made against the service from another domain will be examined to determine whether it is allowed according to the rules you have specified.
To more in detail ref the below documents
Windows Azure Storage and Cross-Origin Resource Sharing (CORS) – Lets Have Some Fun - GauravMantri
Cross-Origin Resource Sharing (CORS) support for Azure Storage | Microsoft Learn
Related
I have a single ASP.NET MVC app - website and API controllers. I'd like to use Azure API Management to manage these APIs but retain the same URL so that it is seamless for our consumers. We have a custom domain setup on the app service for this web app that is currently used to serve up both the site and APIs(e.g. Website: xyz.com, APIs: xyz.com/api1, xyz.com/api2, etc.). Also we use AAD for auth. and have the redirect URI setup to the custom domain(xyz.com). Everything works great at present.
The issue arises after we configure API Management to expose our APIs and potentially use it as a passthrough. In order to ensure that the URLs remain the same after API Management is introduced we set the custom domain to be on the API Management instance itself and removed it from the app. service. This is how our current setup looks -->
User hits xyz.com and the request proceeds as follows -> Traffic Manager -> APIM(xyz.com) -> App Service(xxx.azurewebsites.net)
After that last point above, AAD auth. should kick in and once it has the access token after successful auth. it should redirect the user and the page should load. But it doesn't. Instead we get a blank page and if we refresh it, then and only then does it proceed to auth. and load the page.
We have tried setting our redirect URI to both the custom domain(xyz.com) as well as the base app service name that Azure generated(xxx.azurewebsites.net).
Directly hitting the API urls specifically(e.g. xyz.com/api1) works fine. It goes through APIM and responds as expected. The only problem is that the website doesn't load as outlined above.
The moment we take APIM out of the equation, and set the custom domain back on the app service again, everything works as expected.
I'm trying to figure out if we've misconfigured our assets for this scenario somehow or if APIM doesn't support pass through for the website in this manner. Any thoughts/suggestions here would be much appreciated!
Wow, that was a lot of text.
Ok, let's see:
Visitors -> Traffic manager -> APIM -> backend (your website) - ok got it.
this is like a common way of using APIM, and it should work. However, maybe your policies are not set up correctly?
Have you built your product/API/Operations? Do you see requests coming from APIM hitting your site? What responses are you getting?
Now, of course, you will need to define and set up APIM (products, APIs, and every operation) to pass it throw to your backend. This means if you (as a visitor) need to list all products, you would need to go through the APIM operation (sed GetProducts ). Your request will be passed through the Inbound policy(adjust and build the request if needed), pass it to the backend( to your website with custom APIs), and the response will be sent back from the backend back to the visitor.
Now to this: to protect your Web API Backend in APIM, you could use OAuth 2.0 authorization with Azure AD:
big picture overview:
Register an application (for your backend) in Azure AD to represent the API
Register another Application (the client) in Azure AD to represent a client app that will call your API
And I guess this is the one for you grant permissions to allow the client app to call the backend app
And, of course, add the validate-jwt policy to validate the OAuth token for every incoming request
Read om on this here https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad
I have an application built on laravel. I needed to enable https on my system and I used the cloudfront and Certificate Manager.
I was able to configure everything! Except that the laravel authentication system stopped working. Apparently the session in laravel does not work with cloudFront (CDN).
The system shows no errors. It simply does not authenticate the user.
I suspect the reason is the cloudFront. Because the cloudFront is between the browser and the EC2 server. Anyone know if there is a laravel authentication problem with cloudFront and Certificate Manager
my system: https://loja2.softshop.com.br/login
credentials:
login: teste#sandbox.pagseguro.com.br
password: tim140
the laravel validation also does not show the error messages.
For web distributions, you can choose whether you want CloudFront to forward cookies to your origin and to cache separate versions of your objects based on cookie values in viewer requests.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Cookies.html
By default, no cookies are forwarded by CloudFront. Since most web sites providing any kind of dynamic content use cookies for managing state and authentication, the default configuration usually needs to be modified for dynamic sites.
Note the caveats on the same page of the documentation -- you generally only want to forward cookies to your origin on requests where the origin actually needs to them, so you may want to create separate Cache Behaviors without cookies enabled for static resources, in order to maintain a reasonable cache hit ratio for those static resources.
I already have configured Federation service. I have to use Web API with WS-Federation service. As Federation services use cookies to store security tokens and there is no support of Cookies in Web API. Now, how to use Web API with WS-Federation?
This link discussion will help you:
Invoking webapi throws No Access-Control-Allow-Origin header is present on the requested resource
It states that WebApi uses host's sign-in protocol.
I would like to use my API website for authentication & authorisation of users and ideally keep my UI site purely static content (html, js, css).
I have configured ServiceStack's OAuth & OpenId (and credential/basic) providers, so they answer to api.mysite.com/auth/{provider} requests
I would like to be able to users of www.mysite.com to be able to authenticate and then make calls to the API site via ajax.
The BootstrapApi example project - although very useful - demonstrates the API & website running on the same domain.
Is this possible/secure with a static javascript client?
Could I share a cookie between sub-domains?
Could I return the access token to the client and have use it to calculate an Authorization header before each request?
To address your questions -
Is this possible/secure with a static javascript client? Yes
Could I share a cookie between sub-domains? Yes
Could I return the access token to the client and have use it to calculate an Authorization
header before each request? Sure but you may as well just use the
built in auth cookie.
It's just a matter of setting up your cookies on the top level domain, similar to what's shown # ServiceStack - Authentication for domain and subdomains
I am trying to find out why many developers disable CORS by default in their REST API offerings? Is security the main concern? From the W3C wiki article on CORS support, it looks like it is fairly simple to add CORS support (add a header Access-Control-Allow-Origin with value '*' on the server)
I recently ran into issues when trying to write a simple javascript only app to access Azure tables and other Rest APIs like the ones from Panoptix and ProductWIKI. They had some great REST APIs but wouldn't allow CORS. Azure tables in specific has a stringent authentication process associated with their REST API calls and in spite of that it wouldn't let CORS (at least for the moment).
I would like to hear from developers and Admins of RESTFul APIs on their reasoning behind enabling/disabling CORS for your API offerings? Is security/traffic/compatibility the main concern or is there anything more to it?
When I make Web services I leave off CORS because it is the default setting and only add it if the project requires public browser access to our services. Why same-origin policy is the default is a different question. I've never seen the advantage in disallowing Ajax access from other domains.