We use Netlify to deploy our frontend and use deploy previews to test each PR. This means the URLs we use to access our application is random following the format https://deploy-preview-<RANDOM_STUFF>.netlify.app. When we try to log in using Google OAuth, we get this error:
What's the correct way to handle this? Security is not super important here because it's only staging/qa.
To clarify: Netlify picks up every single branch and PR, and Netlify generates a new URL with <RANDOM_STUFF>. Adding each of them by hand to Google OAuth's configuration is not an option.
The javascript origin configured for your app must exactly match where you are sending from.
In this case https://deploy-preview-<RANDOM_STUFF>.netlify.app
Related
Context:
I have a keycloak inside a docker, I understand that there is a "proxy reverse" doing something like transforming this url for example: "http://example.com" into "http://171.20.2.97:8082" (this is the actual place where the Keycloak is "deployed" or "up"). It is just an example, my clients when they need to consume an endpoint from one microservice of mine do not use numbers, they use example.com.
so in the Keycloak when you want to see the metadata of the realm for SAML2.0 you can do it by following this link which is in the REALM settings section:
https://example.com/auth/realms/REALM-NAME/protocol/saml/descriptor
as you can see I am using "example.com" not "171.20.2.97:8082" to access the metadata link.
The problem is that inside the METADATA, the endpoints for SingleSignOnService, SingleLogoutService, etc. Are all configured to be "http://171.20.2.97:8082/auth/realms/REALM-NAME/protocol/saml" (notice it is using the numbers and not example.com) and this causes that when the clients that want to use SAML.
Send inside their SAML REQUEST "Destination" attribute like so: "http://example.com/auth/realms/REALM-NAME/protocol/saml" and this causes an invalid request error, with reason invalid_destination, because the request attribute Destination was expected to be:
"http://171.20.2.97:8082/auth/realms/REALM-NAME/protocol/saml" like is inside the Metadata.
So my question is, how can I edit the metadata to change the endpoints numbers to example.com or if that is not possible, how can I make example.com get translated to 171.20.2.97:8082 inside my keycloak server? Or if you know another way to solve/figure out this it is very welcome
I feel like a BEAST after finding out how to achieve what I needed after like 3 weeks of searching about keycloak and SAML (I overcame many obstacles this was the lastone), finally I managed to fix this by using the "Frontend URL" setting in my REALM settings, there I can put anything I want so that it changes "http://171.20.2.97:8082/auth/" (inside the metadata urls) for whatever I configure there, so for example if I set Frontend URL to:
https://example.com/auth/
now all my metadata endpoints will be like so:
https://example.com/auth/realms/REALM-NAME/protocol/saml
instead of:
http://171.20.2.97:8082/auth/realms/REALM-NAME/protocol/saml
now my client is being able to properly login with SAML2 using keycloak.
how did I manage to find out this? Well there is not much info so this was what gave me the hint: Keycloak behind nginx reverse proxy: SAML Integration invalid_destination
The person asking said that he configured frontend-url, and I wanted to give a try to that, and after checking if that changed metadata urls, surprise it did =)
I bought a nest thermostat as I thought it would be able to give me detailed data to showing the target temp and the actual as well as time etc. I needed this for various reasons.
However, it seems the official API "Works with Nest" was closed by Google. I've been able to get postman to ping the same location that the Google Nest Webapp hits and get back the data I need. I want to create a simple webapp to keep polling and save the data locally. However, I'm unable to find the OAuth Client Secret that the Nest Webapp uses to get the authorization code. I had to login via the webapp to get the code in one of the request and then test it out using postman.
Is there any other API that will allow my to poll this data for my Nest easier?
If there isn't another API, is there a way to get the Client ID and Client Secret form the Nest Webapp so I can drop that in mine to use? (I know its hacky, but am I think I'm out of options)
I have deployed an application to Heroku and have used the heroku config:set command to set environmental variables such as keys for certain things (Google Maps API, for example). When I view the page and inspect element, the key shows up in the url in the console. Should this be the case? I was under the impression that keys should be kept hidden to keep others from knowing what they are for security reasons. Please advise. Thank you.
You can't. Anything which is sent to the client is not secret. That includes any values used in javascript.
But don't worry - most API's like Google Maps use a public key. And applications where you use Oauth only allow a whitelist of callback domains.
In fact in the Google Maps Javascript API your API key is used in constructing the URLs used to request resources so attempting to hide it would be a true fools errand.
Some API's do however provide client secrets for calling the API from the server side. These should be kept secret and placed in an ENV var on the server.
I'm developing a Google Sheets add-on. The add-on calls an API. In the API configuration, a url like https://longString-script.googleusercontent.com had to be added to the list of urls allowed to make requests from another domain.
Today, I noticed that this url changed to https://sameLongString-0lu-script.googleusercontent.com.
The url changed about 3 months after development start.
I'm wondering what makes the url to change because it also means a change in configuration in our back-end every time.
EDIT: Thanks for both your responses so far. Helped me understand better how this works but I still don't know if/when/how/why the url is going to change.
Quick update, the changing part of the url was "-1lu" for another user today (but not for me when I was testing). It's quite annoying since we can't use wildcards in the google dev console redirect uri field. Am I supposed to paste a lot of "-xlu" uris with x from 1 to like 10 so I don't have to touch this for a while?
For people coming across this now, we've also just encountered this issue while developing a Google Add-on. We've needed to add multiple origin urls to our oauth client for sign-in, following the longString-#lu-script.googleusercontent.com pattern mentioned by OP.
This is annoying as each url has to be entered separately in the authorized urls field (subdomain or wildcard matching isn't allowed). Also this is pretty fragile since it breaks if Google changes the urls they're hosting our add-on from. Furthermore I wasn't able to find any documentation from Google confirming that these are the script origins.
URLs are managed by the host in various ways. At the most basic level, when you build a web server you decide what to call it and what to call any pages on it. Google and other large content providers with farms of servers and redundant data centers and everything are going to manage it a bit differently, but for your purposes, it will be effectively the same in that ... you need to ask them since they are the hosting provider of your cloud content.
Something that MIGHT be related is that Google rolled out some changes recently dealing with the googleusercontent.com domain and picassa images (or at least was scheduled to do so.) So the google support forums will be the way to go with this question for the freshest answers since the cause of a URL change is usually going to be specific to that moment in time and not something that you necessarily need to worry about changing repeatedly. But again, they are going to need to confirm that it was something related to the recent planned changes... or not. :-)
When you find something out you can update this question in case it is of use to others. Especially, if they tell you that it wasn't a one time thing dealing with a change on their end.
This is more likely related to Changing origin in Same-origin Policy. As discussed:
A page may change its own origin with some limitations. A script can set the value of document.domain to its current domain or a superdomain of its current domain. If it sets it to a superdomain of its current domain, the shorter domain is used for subsequent origin checks.
For example, assume a script in the document at http://store.company.com/dir/other.html executes the following statement:
document.domain = "company.com";
After that statement executes, the page can pass the origin check with http://company.com/dir/page.html
So, as noted:
When using document.domain to allow a subdomain to access its parent securely, you need to set document.domain to the same value in both the parent domain and the subdomain. This is necessary even if doing so is simply setting the parent domain back to its original value. Failure to do this may result in permission errors.
I would like to integrate my cloud service in Heroku as an add-on. I read the available tutorials on how to do this, but it is still not clear. https://devcenter.heroku.com/articles/building-a-heroku-add-on#provisioning
I couldn't understand the role of the application that we create from a template (Sinatra for example) using kensa.
Is it an intermediate between Heroku and the cloud service?
thanks in advance.
Actually, Heroku needs 2 things:
addon-manifest.json file where described all information needed for Heroku. And this json file contains 2 important urls:
'base_url'
'sso_url'
Application which will server heroku-specific API and responds wit corresponding JSON on provisioning/deprovisioning/planchange requests. These request point to 'base_url'.
So, if you own your Cloud service code, and can add new API endpoints, then you don't need any application based on kensa-template: add necessary API controllers directly in the service.
But if you can't upgrade the cloud service, then you're right, kensa-template is a ready to use with heroku intermediate.
In case of sinatra template, you just need to put necessary API calls to your cloud service in "# provision" method of app.rb file, deploy app somewhere and do 'kensa push' for your addon-manifest.json (don;t forget to update base_url to yours)
Good luck!
Bare minimum API routes for heroku add-on based on your Cloud service:
POST request to '/heroku/resources' - for provisioning
DELETE request to '/heroku/resources' - for deprovisioning
If you really want to sell it to heroku users, then you should do more stuff:
add support for heroku single sign-on
this is one more API route: POST to '/heroku/sso', but you can change it in addon-manifest.json file.
PUT '/heroku/resources/:id' for Plan change request. Note that ':id' is an id which you provided heroku in your response during provisioning.
If you implement SSO, then user can click on your add-on on heroku instance's resources page and redirect directly to your service bypass any login forms.
You can show just short info about user's resource in the page after SSO.