I have my Meteor app serving for a number of domains. The app's functionality is the same for all sites, but the host names dictate which templates I render.
Everything works fine when I run my Meteor app in production with ROOT_URL pointing to only one of the domains. So I'm wondering, why is this a required environment variable other than for its use in Meteor.absoluteUrl()? (which I personally don't use though I recognize it may be used elsewhere under the hood)
The use of this in production environments is during OAuth callbacks. If you log in via Facebook/Twitter/Google or some other third party it will call back to your domain and your browser has to route this correctly.
In OAuth the domain used must match the one given to the other side for security. The other is so that the OAuth login provider, like facebook knows where to redirect back to.
So this is passed on through the ROOT_URL. e.g for facebook when logging in would redirect back to Meteor.absoluteUrl('_oauth/facebook?close')
Related
I'm trying to build a login page for my Shiny application, using the auth0 services, nginx, node.js and the git repo github.com:auth0/shiny-auth0.git.
You can find the full tutorial here
Everything works fine, except for the fact that I can't login using a valid username/password combination (made within the auth0 webpage). It is possible though to login using for example your Google account (it's redirected to Shiny application, as expected).
The generic error message I get is stating WE COULD NOT REACH THE SERVER. PLEASE CHECK YOUR CONNECTION AND TRY AGAIN.
I can't find any working solutions in the documentation, or on the forum of Auth0. Did anyone experience similar problems, using Auth0, possibly in combination with Ubuntu 16.04, Node.js, R Shiny and Nginx and found a solution?
Help is highly appreciated!
The trick lies in the Allowed Callback URLs and the Allowed Origins (CORS). Both fields need to be filled in properly within the Auth0 Client setup. This means that the allowed callback URL needs to be equal to your domain of the Shiny app, starting with the proper protocol (in this case http) and ending with /callback. The same URL should be used in the .env file. In my case, this was something like http://ec2-123-456-789.eu-central-1.compute.amazonaws.com/callback.
Then don't forget to also use the Allowed Origins (CORS), since the origin is not exactly equal to the callback. The origin uses https protocol, instead of http. Hence use something like https://ec2-123-456-789.eu-central-1.compute.amazonaws.com for your Origin.
I'm developing a website using ASP.NET identity that will work with subdomains that identify a client using some information from here I've got subdomains working locally, but I can't get it to work with OAuth.
For example, if I got to https://localhost:44301 and try to login with Google, everything is fine. In my Google console I have https://localhost:44301 under "Authorized JavaScript origins" and https://localhost:44301/signin-google under "Authorized redirect URIs". But when I go to https://foo.localhost:44301 Google will respond with:
Error: invalid_request
Invalid parameter value for redirect_uri: Non-public domains not allowed: https://foo.localhost:44301/signin-google
When you try to log in. I can add https://foo.localhost:44301 to "Authorized JavaScript origins" in the Google console, but it won't let me add https://foo.localhost:44301/signin-google under authorized redirect URIs because it will complain:
Invalid Redirect: https://foo.localhost:44301/signin-google must end with a public top-level domain (such as .com or .org)
Some other questions and answers suggest redirecting all subdomains to a single domain for OAuth, but ideally I want to keep logins per subdomain. So if you use google to sign it to foo.mydomain.com it will be separate from bar.mydomain.com and I don't think that'll work if I have to redirect both to the same single domain (although I'm not sure that's going to work without separate projects in Google.
Google and in general other OAuth2/OIDC providers will support redirecting to sub-domains. Your specific problem is that you seem to be trying to use sub-domains of localhost which is in the list of Special-Use Domain Names (RFC6761) and it seems Google has additional constraints for those ones.
However, this is not a real limitation because on production you'll use a public top-level domain from from where you'll have the specific sub-domains.
If you need to have this working for local development, you can use localtest.me which allows you to set a sub-domain you like (foo.localtest.me and bar.localtest.me) while still ensuring that the domain resolves to your local machine (127.0.0.1). This should stop Google from complaining about it...
How to prevent someone just taking my API keys from the client side javascript code and starting to use my HERE subscription for some other use.
I noticed HERE provide an option to secure the API keys for a certain domain on the applications management page: "Secure app credentials against a specific domain". I have set up this option and also put domain there but I do not see any change on my app behavior.
The application still continue working fine on my PC. Shouldn't the HERE API stop working as web server is running on localhost and not on the defined domain.
My app is running fully on browser, and only static files come from the server (http://localhost:8083/index.html). I am using the HERE javascript API.
I tested also running the app on external cloud service on different domain than localhost. Results are the same. My conclusion is that the setting "Secure app credentials against a specific domain" just has no impact and does not work. Checked also the api response headers and all origins are accepted.
Access-Control-Allow-Origin: *
In your HERE dashboard, you can set the application id and application code to only work on a particular domain or set of domains. If the tokens are fixed to a domain, it won't matter if someone takes your tokens because only the listed domains can use them. If you don't secure the tokens to a domain, then someone will be able to use your tokens if they find them.
I am the owner of a chrome app which is currently a hosted app on https://mydomain.com. I would like to add push messaging to it, so it will have to become a packaged app.
However, I don't want to lose the ability to prompt users on the website to install the app if they don't already have it installed.
There are many ways I've come up with to test this, but none of them seem satisfactory:
chrome.app.isInstalled, the method I currently use is unavailable for packaged apps.
Inserting a DOM element is a recommended practice, but only available for extensions; content_scripts is disallowed for packaged apps.
Setting a cookie could work, but the cookies permission is disallowed for packaged apps.
Setting a cookie using a webview might be possible, but webviews are sandboxed, and do not share cookies with chrome.
Detecting a file in the app might work, but the web_accessible_resources permission is disallowed disallowed for packaged apps.
Specifying url handlers seems like it might work, but It looks like they only work for urls in the address bar (i.e. they don't seem to handle requests).
Setting externally_connectable works, but it requires a permissions dialog saying that the app would like to "communicate with cooperating websites". The permission is this vague even if I specify https://mydomain.com. I would like to avoid this since people tend not to update apps when permissions change.
Does anyone know of a way to determine whether my packaged app is installed if I own both the app and https://mydomain.com?
url_handlers or externally_connectable is the way to go. You've understandably ruled out the last option because of the extra permission warning (which would disable the app until the user approves the new permission).
url_handlers does offer a solution without requiring extra permissions:
At your server's side, if the user doesn't have any cookies, redirect to some other URL at your server. E.g. http://example.com/landing/ -> http://example.com/landing/?noapp.
If the app is not installed, the redirect will be followed. On that landing page, use history.replaceState(null, null, '/landing/'); to change the URL back to the original URL.
If the app is installed, the chrome.app.runtime.onLaunched will be triggered, and the redirect is not followed. On your website, use setTimeout to check whether or not the page is unloaded.
If the previous method doesn't suit you for some reason, then there is one more (fragile) alternative: Set up an API endpoint at your server and use CORS. Because your app does not have the permission to access this resource, the AJAX request automatically gets an unforgeable request header (Origin: chrome-extension://.../...). You can detect the presence of this header, and mark the app as installed for the specific IP address. If you choose a right frequency, you will have an up-to-date ip-to-app mapping.
This doesn't work for multiple computers behind a NAT though. And I (as a user) would be concerned about my privacy if you kept pinging home...
I have an app buit with Firebase I want to deploy using Trigger.io.
In the App I'm using the auth.login('twitter') function.
What domain name shall I put in the Auth setting of my app?
Thanks a lot !
Following up on this thread in case anyone else is looking for the answer to this.
The OAuth-based authentication providers in Firebase Simple Login use pop-ups (via window.open(...) to initiate login flows, and window.postMessage to safely communicate between the two frames.
In order to enable these social, OAuth-based providers in Firebase Simple Login in the Trigger.io environment, there are a few steps:
Ensure you're loading the latest Firebase Simple Login client from the Firebase CDN, at https://cdn.firebase.com/v0/firebase-simple-login.js.
The Trigger.io environment support does not require an authorized domain configuration in Forge, but still will require that you configure your Facebook / Twitter / GitHub application to use the appropriate https://auth.firebase.com/auth/... redirect URL, as documented.
Ensure that any required Trigger.io JavaScript libraries are included (the forge global variable should be set in your application - test with console.log(forge) in your client code).
Lastly, and most important, the Trigger.io Tabs Module must be enabled in your application config.