I'm using Ruby on Rails, and connecting to the Shopify REST Admin API in my app, to retrieve information for stores. We use the Shopify OAuth2 gem, which handles authentication and access scopes for the API, using the OmniAuth middleware:
Rails.application.config.middleware.use OmniAuth::Builder do
provider :shopify,
ENV["SHOPIFY_API_KEY"],
ENV["SHOPIFY_API_SECRET"],
scope: 'read_orders,read_products',
setup: lambda { |env|
strategy = env['omniauth.strategy']
shopify_auth_params = Rack::Utils.parse_query(env['QUERY_STRING'])
shop = if shopify_auth_params.present?
"https://#{shopify_auth_params['shop']}"
else
''
end
strategy.options[:client_options][:site] = shop
}
end
I want to change which scopes are sent to Shopify during authentication, so some stores get one set of scopes and another store gets a different set. For example, some stores will request the scopes:
read_orders, read_products
While another store requests:
read_orders, read_products, read_inventory
The reason for this is to allow users to choose when they would like to upgrade the app themselves, and not be forced to do so when changing scopes needed by the app.
How I can pass in additional information dynamically?
I solved this by following along on this GitHub issue: https://github.com/Shopify/omniauth-shopify-oauth2/issues/60
You can pass in the scopes dynamically through the session, and set it in the setup block of OmniAuth:
Rails.application.config.middleware.use OmniAuth::Builder do
provider :shopify,
ShopifyApp.configuration.api_key,
ShopifyApp.configuration.secret,
setup: lambda { |env|
strategy = env['omniauth.strategy']
session = strategy.session.with_indifferent_access
env['omniauth.strategy'].options[:scope] = session['shopify.oauth.scope']
...
}
It might be smarter to think of this in different terms. You probably do not want to use scopes in the world of differentiating your App. Instead, you will focus on actual functionality delivered to the merchant. Pay more, get more. So when you install the App, to make your life easier, you have one set of scope for all installs. You avoid the dreaded modal popup asking for new scopes later, likely resulting in confusion and uninstalls.
Even if the most restricted App has maximum scope, the merchant cannot do anything with that if you architected your App to limit their functionality. So you might want to build in to your App just that. You decide what the App delivers by inspecting the current subscription plan they are paying for instead of worrying about scope.
TL:DR; using scope to decide what your App does is a bad idea.
Related
I have a rails app set up as an OAuth2 provider (using Doorkeeper). The app uses a different subdomain per user account (or an entirely different domain through a cname record)
i.e.
user1.myrailsapp.com
user2.myrailsapp.com
www.mycustomdomain.com
On the provider side, everything is working as expected.
I also have a second app that is a client making use of the first app's exposed API. I have a version of the client working but only with a hard coded site url in the OmniAuth strategy.
The question is, how can I dynamically set the strategy url on a per request basis.
For anyone interested, the solution is in the use of dynamic providers: https://github.com/intridea/omniauth/wiki/Dynamic-Providers
Rails.application.config.middleware.use OmniAuth::Builder do
provider :mystrategy, ENV["OAUTH_ID"], ENV["OAUTH_SECRET"],
:setup => lambda{|env|
env['omniauth.strategy'].options[:client_options].site = env['rack.session']['oauth_site']
}
end
One option is don't do it that way.
I have a similar app and ran into the same issue. However after thinking about it for a moment I realised that I didn't want to send them to a strategy provider URL on the user account's subdomain because the request wasn't yet fully authenticated (it hasn't been processed by the rails app yet).
Also for the first time a user logs in the user account subdomain hadn't yet been set up, so it would have been impossible to route there.
So instead, I have the strategy callback URL set to the main website. After the signin request is processed, session set up and everything, then I redirect the client onto their user subdomain. Takes out a whole load of pain.
My two rails applications(app1, app2) are communicating using active resource.
app1 calls app2 create a user inside app2. app2 would create the user and would like app1 then redirect the user to app2's authenticated pages.
going from app1 to app2 would invariably ask the user to log in.
I was looking for a way to avoid this login step in app2, instead make the user log in during the first active resource call to create user, and somehow get the authentication token written.
Authentication is done using Devise. Is there anything built into Devise that support this?
Is passing around the authentication token the way to go?
You are trying to implement a form of Single Sign-On service (SSO) (sign in with app1, and be automatically authenticated with app2, app3...). It is unfortunately not a trivial task. You can probably make it work (maybe you already did), but instead of trying to reinvent the wheel, why not instead integrate an existing solution? Or even better, a standard protocol? It is actually relatively easy.
CAS server
RubyCAS is a Ruby server that implements Yale University's CAS (Central Authentication Service) protocol. I had great success with it.
The tricky part is getting it to work with your existing Devise authentication database. We faced the same problem, and after some code diving, I came up with the following, which works like a charm for us. This goes in your RubyCAS server config, by default /etc/rubycas-server/config.yml. Of course, adapt as necessary:
authenticator:
class: CASServer::Authenticators::SQLEncrypted
database:
adapter: sqlite3
database: /path/to/your/devise/production.sqlite3
user_table: users
username_column: email
password_column: encrypted_password
encrypt_function: 'require "bcrypt"; user.encrypted_password == ::BCrypt::Engine.hash_secret("#{#password}", ::BCrypt::Password.new(user.encrypted_password).salt)'
enter code here
That encrypt_function was pain to figure out... I am not too happy about embedding a require statement in there, but hey, it works. Any improvement would be welcome though.
CAS client(s)
For the client side (module that you will want to integrate into app2, app3...), a Rails plugin is provided by the RubyCAS-client gem.
You will need an initializer rubycas_client.rb, something like:
require 'casclient'
require 'casclient/frameworks/rails/filter'
CASClient::Frameworks::Rails::Filter.configure(
:cas_base_url => "https://cas.example.com/"
)
Finally, you can re-wire a few Devise calls to use CAS so your current code will work almost as-is:
# Mandatory authentication
def authenticate_user!
CASClient::Frameworks::Rails::Filter.filter(self)
end
# Optional authentication (not in Devise)
def authenticate_user
CASClient::Frameworks::Rails::GatewayFilter
end
def user_signed_in?
session[:cas_user].present?
end
Unfortunately there is no direct way to replace current_user, but you can try the suggestions below:
current_user with direct DB access
If your client apps have access to the backend users database, you could load the user data from there:
def current_user
return nil if session[:cas_user].nil?
return User.find_by_email(session[:cas_user])
end
But for a more extensible architecture, you may want to keep the apps separate from the backend. For the, you can try the following two methods.
current_user using CAS extra_attributes
Use the extra_attributes provided by the CAS protocol: basically, pass all the necessary user data as extra_attributes in the CAS token (add an extra_attributes key, listing the needed attributes, to your authenticator in config.yml), and rebuild a virtual user on the client side. The code would look something like this:
def current_user
return nil if session[:cas_user].nil?
email = session[:cas_user]
extra_attributes = session[:cas_extra_attributes]
user = VirtualUser.new(:email => email,
:name => extra_attributes[:name],
:mojo => extra_attributes[:mojo],
)
return user
end
The VirtualUser class definition is left as an exercise. Hint: using a tableless ActiveRecord (see Railscast #193) should let you write a drop-in replacement that should just work as-is with your existing code.
current_user using an XML API on the backend and an ActiveResource
Another possibility is to prepare an XML API on the users backend, then use an ActiveResource to retrieve your User model. In that case, assuming your XML API accepts an email parameter to filter the users list, the code would look like:
def current_user
return nil if session[:cas_user].nil?
email = session[:cas_user]
# Here User is an ActiveResource
return User.all(:params => {:email => email}).first
end
While this method requires an extra request, we found it to be the most flexible. Just be sure to secure your XML API or you may be opening a gapping security hole in your system. SSL, HTTP authentication, and since it is for internal use only, throw in IP restrictions for good measure.
Bonus: other frameworks can join the fun too!
Since CAS is a standard protocol, you get the added benefit of allowing apps using other technologies to use your Single Sign-On service. There are official clients for Java, PHP, .Net and Apache.
Let me know if this was of any help, and don't hesitate to ask if you have any question.
I've received a token / secret from a service using OmniAuth and can store it for users, but I'm stuck as to how to actually use these to call a service.
The closest thing I've seen to this question is here but the way he's solved that there doesn't feel right. I feel like OmniAuth likely does this all for you if you know what you're doing.
Netflix has a pretty involved auth process, so I was hoping to skirt all of this by using OmniAuth to abstract me from all of this.
Given that I have a token and secret for a user, how to use these in calling a service like Netflix?
Many thanks :)
Hey, I'm the author of the OmniAuth gem. OmniAuth is meant to be used for the authentication process. In the case of OAuth providers like Netflix, this means exchanging a request token for an access token which is then used to pull user information from the API. These one-off calls are specifically designed for each provider and are not meant to be a generic API client for the given provider.
What you can do it use OmniAuth to obtain the credentials and then use another specific library for the site itself (such as ruby-netflix or anything else, I'm not sure what the best one is) to make calls. You can retrieve the access token and secret that is obtained in the authentication dance by accessing env['omniauth.auth']['credentials'], then use those to initialize the API client.
You can also use the OAuth library directly to make these calls, but I would strongly recommend just using an existing library, it will be much faster and easier. Does all of that make sense?
OmniAuth is all about authentication; you should probably look at another gem for making actual calls to the service. E.g., for Facebook, I use the OAuth2 gem and code like the following:
module Facebook
class Client < OAuth2::Client
# Return a new OAuth2::Client object specific to the app.
def initialize
super(
APP_CONFIG[:facebook][:api_key],
APP_CONFIG[:facebook][:app_secret],
:site => 'https://graph.facebook.com',
:parse_json => true
)
end
end
class Token < OAuth2::AccessToken
# Return a new OAuth2::AccessToken specific to the app
# and the user with the given token.
def initialize(token)
super(
Facebook::Client.new,
token
)
end
end
end
access_token = Facebook::Token.new(users_fb_token)
url = "https://graph.facebook.com/#{user_fb_id}/feed"
response = access_token.post(url, :message => "My update")
Note that there are gems for popular services, like Facebook and Twitter, that can manage the behind-the-scenes things like creating tokens, managing URLs, etc. For Netflix, you might check the following:
https://github.com/tiegz/ruby-netflix
https://github.com/rares/netflix
http://code.google.com/p/flix4r/
Also keep in mind that OmniAuth just returns the service data to you; you're free to store it and use it how you will (Devise has it's own pattern for OmniAuth that you might butt heads with if you try to go outside the lines). The other question you linked doesn't look too far fetched to me.
I have a rails app that is accessible from 2 domains. Facebook requires me to register a facebook app for each of these domains and gives me credentials for each. With Omniauth I can only specify one set of credentials that is set on application startup. However, I would need to supply FB with different credentials depending on the host of the request.
There are 2 problems here:
How can I change the Omniauth credentials for facebook at runtime?
How can I intercept the call to facebook, check the domain and set the credentials accordingly? A before filter will not work, as Omniauth uses Rack Middleware.
Any suggestions are highly appreciated!
Copying the answer from the comments in order to remove this question from the "Unanswered" filter:
I solved this myself now. The problem was that the fb strategy calls
back to fb a second time to get an access token. In that second call
the wrong credentials were used (the ones set in the initializer). So
I had to patch the OAuth2 strategy so that it calls through to the
rails app again, to set the runtime credentials for that second call.
In the call back, which normally only handles the response form
Omniauth, I set the credentials and return a 404 unless
request.env["omniauth.auth"] is present. That works fine but has some
side effects for apps without dynamic providers.
The problem is now, that even if an application doesn't want to set the credentials at runtime, it has to add a condition to the callback like if request.env["omniauth.auth"] to avoid the callback code being executed when it is called the first time. The solution is probably to add a parameter to the Omniauth builder like :dynamic_provider and only call through to the app if it is set.
~ answer per Nico
This question is fairly old but still relevant. Nowdays it is also possible to set provider details dynamically during OmniAuth's Setup Phase.
For example:
Rails.application.config.middleware.use do
provider :example,
setup: ->(env) do
env['omniauth.strategy'].options[:foo] = env['rack.session']['foo']
env['omniauth.strategy'].options[:client_options][:site] = Something.dynamic('param')
end
end
Source: https://github.com/omniauth/omniauth/wiki/Dynamic-Providers
Is anyone aware of any gems, tutorials, or solutions enabling a user to sign in to a website at one domain and automatically given access to other partner domains in the same session?
I have two rails apps running, let's call them App-A and App-B. App-A has a database associated with it, powering the registration and login at App-A.com. I'd now like to give all of those users with App-A.com accounts access to App-B.com, without making them reregister or manually login to App-B.com separately.
Thanks in advance for any help!
--Mark
You can set the same session_key in both apps. In appA environment.rb change the session_key, like this
Rails::Initializer.run do |config|
...
config.action_controller.session = {
:session_key => '_portal_session',
:secret => '72bf006c18d459acf51836d2aea01e0afd0388f860fe4b07a9a57dedd25c631749ba9b65083a85af38bd539cc810e81f559e76d6426c5e77b6064f42e14f7415'
}
...
end
Do the same in AppB. (remember to use the very same secret)
Now you have shared sessions. Let's say you use restfull_authentication, wich sets a session variable called user_id. When you authenticate in appA it sets the user_id in the session. Now, in appB you just have to verify if user_id exists in the session.
This is the overall schema, you can elaborate more using this idea.
If you want to create single sign-on solution for your applications then I recommend to take a look at RubyCAS solution. It could be used also to provide single sign-on for other non-Rails applications as well as you can integrate authentication with LDAP or other authentication providers.