I am setting up a Ruby on Rails app to allow login via Facebook with Devise + Omniauth. I can got this working no problem with the APP ID and Token.
However I am having an issue that I am not sure how to get around.
I have 1 instance of the Rails app running on Server A I have 2 domain names www.domain-one.com and www.domain-two.com which point to Server A When I create the app in Facebook for www.domain-one.com it works ok but as soon as I add www.domain-two.com to the app domains it gives me and error "domain must be derived from your Site URL". Is it possible to allow multiple domains login with the same Facebook APP IDs?
If not then would an acceptable solution be to switch the details in the devise initializer file based on domain and does anyone know how to get the domain from an devise initializer?
Hope you understand what I mean.
Tony
You can specify multiple subdomains but they can only belong to one domain. That's because it must match the URL in the Website with Facebook Login > Site URL.
In this case, you can make one domain name as primary domain pointing to server A and the other one as secondary domain redirecting to first domain. then In facebook app use the second domain as site url.
There is another benefit of following this strategy, your websites SEO will be improved. if search engines find one content from different domains then it rank down the content, unique content from unique address increases the ranking.
Related
I'm building an application that has a core hub, say it's called musictickets.com
We'll provide a subdomain (bandname1.musictickets.com) to bands on which only their content will display, which they can mask using a CNAME record to be part of their domain - so tickets.bandname1.com
There would be multiple bands using the platform so you'll end up with pages at
tickets.bandname1.com
tickets.bandname2.com
etc.
I'd like a user who registers at tickets.bandname1.com to be automatically logged in on every site that uses the service, including the parent, musictickets.com . They should be able to register/login using OAuth or directly via form based authentication.
I'm looking at SAML (specifically https://github.com/aacotroneo/laravel-saml2) as one option, but want to throw this out to the wider community for comment.
I've also looked at using token based SSO as described here (single sign on (sso) laravel) and running an auth server (which I may do in any case). Alternatively, I've looked at using iframes to provide the functionality which feels quick but dirty.
As I understand it, I wouldn't be able to use cookies (for an API key for instance) because whilst all of the content will be displayed via a subdomain, the CNAME would make it a different domain.
Does anyone have any thoughts on the best strategy?
I am developing a structure in Google developer console to create projectsnd configure a OAuth 2.0 client IDs for our company websites. These we use to integrate Google login to the website.
We have around 50 websites now, where some are "company websites", then we have "product websites", etc. such groups.
For example group of company websites - those websites have exactly the same design, the same purpose, but are country specific, thus:
- differ in country prefix, e.g. countryA.companyxy.com, countryB.companyxy.com
- differ in content (types of content are the same, but the ontent itself is connected to the country, thus local)
- the language can be different (although mostly it's english)
I am seeking a recommendation as I cannot decide what is better:
1) Create one project per website and then different Client IDs for environments (prod, staging, dev) - this would be 50 projects, each with 3 Client IDs
2) Create one project per a group - e.g. company websites would have one project and I would create new Client ID for each country and each environment. This way I would have maybe 5-6 projects, each with 10-20 Client IDs.
Can those company websites all use the same application, or they should not?
If I've understood you correctly, this is a fairly standard multi-tenant application where a single app (from Google's perspective) lives at multiple domains. You can use a single Project and a single Client-ID, since in both cases, the ID relates to the app, not to the domain the app lives at.
So, when you start the OAuth dance, you always specify the same redirect URL, which handles OAuth for all domains. The trick is that you include a state parameter at the start of the dance which indicates which country/site your OAuth code should redirect to once the dance is finished.
So, roughly something like this:-
user visits countryA.companyxy.com and requests Oauth (eg. clicks a signin button)
You redirect to accounts.google.com?redirect_uri=common.companyfoo.com/oauth&state=countryA.companyxy
After auth, google will redirect back to common.companyfoo.com/oauth?state=countryA.companyxy
Your oauth handler does its thing, then parses the state param and redirects back to countryA.companyxy.com
Of course there might be administrative reasons for your company to prefer multiple projects and/or client IDs depending on your enthusiasm for admin, and how you wish to segment your data. To explain this last point using Drive as an example, if all companies have the same project, then the drive.file scope would give them all access to the files created by the app. However, if you have a project for each company, then Google sees these as created by different apps, so the are not visible using the drive.file scope.
I am seeking a recommendation as I cannot decide what is better:
I would align the Folder/Projects in the same structure as the company organization with a preference towards more projects (separation) instead of consolidation. Try to think of the chain of command and the distribution of resources. Factor in how you want security to separate resources. This might help figure out what should go where. Do separate development from production resources (separate projects).
Can those company websites all use the same application, or they
should not?
The answer is "it depends". If they all share a common domain name root, and they authenticate at the root, very easy to implement. The authentication cookies can be shared across domains. Otherwise, you will need to use multiple redirect_urls so that auth on one site completes on the same site. I am not sure what the limit is for Redirect URLs per Client ID.
To the second part of your question "or they should not". If the websites are designed to look like the same company then customers will expect to only authenticate once and be authorized across all sites. Is this a good idea, Yes. Is it the correct idea, this depends on your security requirements, isolation needs, etc. No simple answer here.
what value to give in the yammer app redirect uri if I want this app to be used by multiple different sites having multiple different domains.
I mean, I have two different sites abc.com and cde.com which will use the same app. So, what should be given in the redirect URI of the app.
There are no strict rules for the redirect URI value, but you MUST ensure that the URL is valid and accessible from your user's locations. See here for further details.
You cannot use a single app for multiple websites. If you have two websites, you have to create two apps and you can change the app-code and redirect url at the run time accordingly.
I want to user Dropbox chooser API for my Ruby on rails application(This is not web app, This will be installed as standalone).
Issue is in specifying "Drop-ins domains", which currently i gave as "localhost. But for the machines on which it will be installed "machine name" will be used instead of localhost. And i cannot keep track of all installations and manually adding those domains
Please suggest, Is there some way to solve this problem? Can i use chooser API without drop-in domain?
The Dropbox Drop-ins API doesn't have any way of automatically adding domains, or registering any sort of wildcard, but we're tracking this as a feature request.
For reference, one thing that does work, though it sounds like it may not apply to your scenario, is registering just, for example, example.com, which would enable use on any subdomain of example.com, e.g., sub1.example.com, sub2.example.com, webmail.example.com, etc.
Alternatively, you can embed an iframe containing the button, which would be hosted on your own domain. This would let you just set that one domain in the app options page. It would be very important that you then restrict the set of domains that you allow to iframe your button though, but this list would now be under your control so you can set it programmatically. For example:
How to limit display of iframe from an external site to specific domains only
I sat up facebook connect extension on my magento store, which allows customer to login to the store with their facebook account. After filling api key, api secret in magento and config site url in facebook apps, the extension worked perfectly. However, if I switch to another store (with another domain), it won't work anymore. Is there a way to have magento connect to facebook without matching site url?
Here is the extension I got from: http://inchoo.net/ecommerce/magento/facebook-connect-magento-extension/
I'm not fully aware of how that Magento app works internally, however what I would say is that Facebook strictly speaking, does not allow apps to work across multiple different URLs. You can add multiple subdomains, however.
There is also some unsupported functionality allowing you to run apps across different domains details in this question, though it's worth remembering, this is unsupported.
The Facebook docs have some more info on "App Domains", and how they should be configured.