I am trying to get hls / dash streams working via Google Cloud CDN for a video on demand solution. The files / manifests sit in a Google Cloud Storage Bucket and everything looks properly configured since i followed every step of the documentation https://cloud.google.com/cdn/docs/using-signed-cookies.
Now i am using an equivalent Node.js code from Google Cloud CDN signed cookies with bucket as backend to create a signed cookie with the proper signing key name and value which i previously set up in google cloud. The cookie get's sent to my load balancer backend in Google Cloud.
Sadly, i always get a 403 response saying <?xml version='1.0' encoding='UTF-8'?><Error><Code>AccessDenied</Code><Message>Access denied.</Message></Error>.
Further info:
signed urls / cookies is activated on load balaner backend
IAM role in bucket for cdn-account is set to "objectViewer"
signing key is created, saved and used to sign the cookie
Would really appreciate any help on this.
Edit:
I just tried the exact python code google states to create the signed cookies from https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/cdn/snippets.py with the following params:
Call: sign_cookie('http://cdn.myurl.com/', 'mykeyname', 'mybase64encodedkey', 1614110180545)
The key is directly copied from google since I generated it there.
The load balancer log writes invalid_signed_cookie.
I'm stumbling across the same problem.
The weird thing is that it doesn't work correctly only in web browsers. I've seen GoolgeChrome and Safari return a 403 even though they contain cookies. However, I have noticed that the same request with the exact same cookie in curl returns 200. I think this means that it does not work correctly in web browser. I'm asking GCP support about this right now, but I'm not getting a good answer.
Edit:
As a result of several hypotheses and tests, I found out that when the cookie library I use formats and inserts values into the Set-Cookie header, URLEncoding is automatically executed and cookies that CloudCDN cannot understand are sent. Therefore, it is now possible for web browsers to retrieve content by adding it to the Set-Cookie header without URLEnconding.
Related
Infra of system
Expected:
I want to block requests, which is not from Server FE (domain.com)
Ex: Users make request from another apps such as Postman -> it will response 403, message access denied.
I used the rules of ALB, it works but users can cheat on Postman
Also I use AWS WAF to detect request. But it's not work.
Is there any way to block request from Postman or another apps?
We can generate secret_key and check between Server FE and Server BE. But users can see it on Headers and simulator the headers on Postman and call API success.
Current Solution:
I use Rule of Application Load Balancer to check Host and Origin. But users can add these params on Postman and request success.
Rule ALB
When I add Origin matching value (set on ALB) -> We can request successful
Postman success
Postman denied
Users can cheat and call API success.
Thanks for reading. Please help me give any solution for this one. Thanks a lot.
No. HTTP servers have no way to know what client is being used to make any HTTP request. Any HTTP client (Browsers, PostMan, curl, whatever) is capable of making exactly the same requests as each other.
The user-agent header is a superficial way to do this, but it's easy enough for PostMan or any other HTTP client to spoof the user-agent header to one that makes the request look like it is coming from a web browser agent.
You can only make it more challenging to do so. Some examples to thwart this behavior includes using tools like Google captcha or CloudFlare browser integrity check, but they're not bulletproof and ultimately aren't 100% effective at stopping people from using tools/automation to access your site in unintended ways. At the end of the day, you're limited to what can be done with HTTP, and PostMan can do everything at the HTTP layer.
If I set the Api Key restrictions to "None", the service works great. If I set the Http referrers to websites, it works as expected with certain websites. If I set the Http referrers to the Urls of Web API Servers, I get a "restricted" message. Does anyone know how to allow the Url of the Web API Server to make a successful call when restrictions are being used? I would think that api.somedomain.com would work.
Looks like it might not be possible. Wow, what a shame! Hopefully, there is an update or workaround for this.
How to set Google API key restriction - HTTP referrers
By the way, this doesn't work either. This is an example in their documentation.
():somedomain.com/
(*): .somedomain.com/
I have to write the full sub domain to all my website Urls.
Thanks in advance!
What I ended up doing is creating another Api Key for my Web API Server requests. Since this key isn't displayed in a website, I shouldn't have to lock it down.
I have mysite.com and mysite.nl.
I want to build single sign-on, someone signing in on .com should be signed in in .nl.
I do this by putting an image (1 pixel transparent PNG image) on the .nl domain which sends back a cookie in the response.
In my firefox dev tools, I see 'response cookie' and it's set. It looks like this:
I have made sure the domain is set to mysite.nl
But somehow, when I then navigate to mysite.nl I don't see the cookie set. Am I missing something? I tried disabling tracker blocking, but to no avail.
Google is doing it this way as well right? Ie., log in in Google and you're logged in in Youtube.
If the browser makes a request to xyz.mysite.com, it has to drop the domain cookie for mysite.nl. This is due to the browser security model. If you want to achieve Single Sign On between xyz.mysite.com and xyz.mysite.nl you need some technology to 'transfer' the session token between the two domains. Either you use a standards-backed technology like SAML or OIDC or you use a proprietary mechanism. If you carefully look at the HTTP response, you will see two Set-Cookie HTTP response headers, one has domain property set to mysite.com, one has set domain property to mysite.nl.
I've been attempting to get cloudfront signed cookies setup for a site to make getting HLS manifest segment files easier to authenticate. Setting up the cloudfront origin and code in a live environment seems simple enough looking at resources like
https://mnm.at/markus/2015/04/05/serving-private-content-through-cloudfront-using-signed-cookies/
http://www.spacevatican.org/2015/5/1/using-cloudfront-signed-cookies/
What I'm trying to figure out is if it's possible to to have this working in a local environment (localhost) prior to deploying the initial solution. Cloudfront itself will forward to the live origin which will set the cookies for cloudfront and continue on as normal, but since the code isn't live this will not work until deployed.
Seems like a chicken and egg problem here where I need it live to use it, but can not test it (with code or manually) without it deployed.
Any thoughts here?
You'd not be able to test/run it properly on your localhost. When you try to set cookies for your CloudFront URL, you'll encounter cross domain issue. I'd recommend you to try generate signed URL first. If signed URL works, that means you're on the right direction. Setting up a cookie cannot go wrong as long as you've properly set CNAME in the CloudFront Web distribution and CloudFront URL records are set within your domain provider.
I've been using WSO2 API Manager 1.9.1 for the past month on a static IP and we liked it enough to put it on Azure behind a full qualified domain name. As we are still only using for internal purposes, we shut the VM down during off hours to save money. Our Azure setup does not guarantee the same IP address each time the VM restarts. The FQDN allows us to always reach https://api.mydomain.com regardless of what happens with the VM IP.
I updated the appropriate config files to the FQDN and everything seems to be working well. However! The one issue I have and cannot seem to resolve is calling APIs from the API consoloe. No matter what I do, I get a response as below
Response Body
no content
Response Code
0
Response Headers
{
"error": "no response from server"
}
Mysteriously, I can successfully make the same calls from command line or SOAPUI. So it's something unique about the API Console. I can't seem to find anything useful in the logs or googling. I do see a recurring error but it's not very clear or even complete (seems to cut off).
[2015-11-17 21:33:21,768] ERROR - AsyncDataPublisher Reconnection failed for
Happy to provide further inputs / info. Any suggestions on root cause or where to look is appreciated. Thanks in advance for your help!
Edit#1 - adding screenshots from chrome
The API Console may not be giving you response due to following issues
If you are using https, you have to type the gateway url in browser and accept it before invoke the API from the API Console (This case there is no signed certificate in the gateway)
CORS issue which may due to your domain is not in access allow origins response of Options call
If you create a API which having https backend. You have to import endpoint SSL certificate to client-trustore.jks