Introduction:
I am building a facebook app which auto wishes happy birthday. I am building it in Rails and using a ruby API wrapper called fb_graph. The creator of fb_graph has graciously provided a working sample application fb_graph_sample
After playing around with it, I do not understand how the sessions/cookies work. For example, check out this code:
def require_authentication
authenticate Facebook.find_by_id(session[:current_user])
rescue Unauthorized => e
redirect_to root_url and return false
end
def authenticate(user)
raise Unauthorized unless user
session[:current_user] = user.id
end
Where does session[:current_user] comes from?
Under config/initializers/session_store.rb,
FbGraphSample::Application.config.session_store :cookie_store, :key => '_fb_graph_sample_session'
So, I look at the cookies for localhost which is where I am deploying it as using Chrome inspector tools, I see _fb_graph_sample_session with value, domain, path, expires, size, http, etc...
I still don't see how session[:current_user] comes about? Looking at the development.sqlite3 file, there is only 1 data for the facebook model. The id is 1 so, that leads me to believe that [:current_user] is 1 and the code is calling 'authenticate Facebook.find_by_id(1)'
Can someone please explain how session[:current_user] translate to 1? I read railstutorial.org chapter on signing-in-out and it creates a sessions controller but there is no sessions controller in the fb_graph_sample app.
Thanks,
I get's set in the authenticate method:
session[:current_user] = user.id
The app is using cookie based session store, when a user logs in a cookie (think of it as a special hash) is written to his browser. You use session pretty much as a hash, you can set as shown above, or get, i.e.
<%= "logged in as #{User.find(session[:current_user]).name}" %>
Related
I'm currently working on a solution for doing redirects in RoR because I got an error within the brakeman report saying that I have to fix redirects in a proper way.
I understand what the message says and how to solve it within one controller action.
But now I got the following. During the instantiation of the new method I set the HTTP_REFERER header which can be used in the create action.
This is giving me a Brakeman warning which can be found on the following link
Suppose I got the following controller with multiple endpoints:
def new
#my_model_set = MyModel.new
#referer = request.env['HTTP_REFERER'] # We want to redirect to this referer after a create
end
def create
...
if #my_model_set.save
flash_message :success, t('notification.item_created', type: #my_model_set.model_name.human)
if params[:referer].present?
redirect_to params[:referer]
else
redirect_to admin_my_model_set_path
end
else
...
end
end
I already tried to fix this by using the redirect_back method from RoR but that's using the referer link of the create method which I don't want to use.
if #my_model_set.save
flash_message :success, t('notification.item_created', type: #my_model_set.model_name.human)
redirect_back(fallback_location: admin_my_model_set_path)
else
...
end
The main problem in your code is that params[:referer] can be set by your user (or an attacker forging a link for your user) to an arbitrary value by appending ?referer=https://malicious.site to the url. You will then redirect to that, which is an open redirect vulnerability.
You could also argue that the referer header is technically user input, and you will be redirecting to it, but I would say in most cases and modern browsers that would probably be an acceptable risk, because an attacker does not really have a way to exploit it (but it might depend on the exact circumstances).
One solution that immediately comes to mind for similar cases would be the session - but on the one hand this is a rest api if I understand correctly, so there is no session, and on the other hand, it would still not be secure against an attacker linking to your #new endpoint from a malicious domain.
I think you should validate the domain before you redirect to it. If there is a common pattern (like for example if all of these are subdomains of yourdomain.com), validate for that. Or you could have your users register their domains first before you redirect to it (see how OAuth2 works for example, you have to register your app domain first before the user can get redirected there with a token).
If your user might just come from anywhere to #new and you want to send them back wherever they came from - that I think is not a good requirement, you should probably not do that, or you should carefully assess the risk and consciously accept it if you want to for some reason. In most cases there is a more secure solution.
I’m currently working on changing the rails backend of a project from REST to graphql and I’m running into an error with authentication following their tutorial - https://www.howtographql.com/graphql-ruby/4-authentication/
I’m using the GraphiQL engine to test all my requests and receiving error status 422 unprocessable Entity, User Must Exist
Which makes sense because the mutation I am executing is to create a new color - which has a belongs_to relationship to User.
About halfway through the page linked above ^^^ it says this:
With the token that the signinUser mutation provides, apps can
authenticate subsequent requests. There are a couple of ways this can
be done. In this tutorial, we are just going to use the built-in
session, since this doesn’t add any requirements to the client application. The GraphQL server should be able to get the token from
the session header on each request, detect what user it relates to,
and pass this information down to the resolvers.
I’m able to successfully return an auth token through the signinUser method like the docs show previously on the same page - the method that it posts to also saves the token to this supposed session in this method here (also from the same link posted above ^^^) :
def call(_obj, args, ctx)
input = args[:email]
return unless input
user = User.find_by email: input[:email]
return unless user
return unless user.authenticate(input[:password_digest])
crypt = ActiveSupport::MessageEncryptor.new(ENV["SECRET_BASE_KEY"])
token = crypt.encrypt_and_sign("user-id:#{ user.id }")
puts "please **********************************"
p ctx[:session]
ctx[:session][:token] = token
puts "please **********************************"
p ctx[:session]
OpenStruct.new({
user: user,
token: token
})
end
You’ll be able to see in my desperate struggle that I p’d out the session right before the method returns and not surprisingly saw that it contained the token for that users sign in.
However, when I proceeded to execute the mutation to create a color, my expectation was that the session would still contain that token and I’d be able to commit that color successfully. That was not the case and when I p’d out the session for this request, it return an empty hash.
I cant find any information about how the built in graphql session works - and I’m brand new to graphql in general.
My main questions would be - is the graphql session supposed to be caching token information? Why is it that the information is not carrying over to requests following signinUser ? Should I even bother with trying to use the auth in this tutorial since the docs claim that this authentication method is not a long term solution?
I know this is a lot but would really appreciate an extra brain on this.
Thanks in advance!
PS. I understand the tutorial uses links and I am using colors here - that is intentional and I have done my best to make sure that semantic differences were not causing any errors.
Rails version - 5.2.2 (using api only)
graphql - 1.7.4
graphiql rails - 1.4.4
Same as REST APIs GraphQL does not store any information between two subsequent requests, You have to pass authentication token returned in sign in mutation to all subsequent requests where you want current user-related information.
You should do something like below in graphql_controller.rb
class GraphqlController < ApplicationController
def execute
variables = ensure_hash(params[:variables])
query = params[:query]
operation_name = params[:operationName]
context = {
current_user: current_user
}
result = GraphqlTutorialSchema.execute(query, variables: variables, context: context, operation_name: operation_name)
render json: result
end
private
# set current user here
def current_user
# you can token here
token = request.headers['Authorization']
return nil unless token
# find current user from this token
end
# Handle form data, JSON body, or a blank value
def ensure_hash(ambiguous_param)
# ...code
end
end
A colleague of mine pointed out that "session" is part of rails and should create a cookie that would be accessible from the next request.
I mentioned that I was using Rails version - 5.2.2 (using api only) - well when you use the -api flag when initializing a new rails project, it adds these lines to application.rb
# Settings in config/environments/* take precedence over those specified here.
# Application configuration can go into files in config/initializers
# -- all .rb files in that directory are automatically loaded after loading
# the framework and any gems in your application.
# Only loads a smaller set of middleware suitable for API only apps.
# Middleware like session, flash, cookies can be added back manually.
# Skip views, helpers and assets when generating a new resource.
config.api_only = true
Notice this line in particular - Middleware like session, flash, cookies can be added back manually.
I commented out config.api_only = true and this added cookies back to the application/ allowed me to make the next request with an existing user.
You can also add these lines I found from "Lysender" on his post - Rails 5 – API Only – Enable Cookies and Sessions if you'd prefer not to remove the api-only feature.
config.api_only = true
config.middleware.use ActionDispatch::Cookies
config.middleware.use ActionDispatch::Session::CookieStore, key: '_coookie_name', expire_after: 30.days
I've got a number of security concerns about my current application and wondering if I am leaving myself open to abuse, in the following arenas.
a) .My main access control method is by maining a current_user, current_company current_project method in my application controller. These methods return object based on stored session keys established when a user logs in and cleared when they log out. I.e if I want to know something about the current user, I can call "current_user.role" or if I want see whether the account a user is trying to change belongs to him, I check whether the associated account id which is requested in the url actually belongs to that user, essentially as follows
in Account controller
def account_info
redirect_to login_path if !user.logged_in
account_id=params[:account_id]
#account = Account.find(account_id)
unless account_belongs_to_user(account_id)
redirect_to unauthorized_path
end
end
In my application controller, when a user is initially authenticated, I do something like this:
session[:current_user_id] = user.id
and clear that session key when the user logs out.
Then when account is requested, and account_belongs_to_user is called, the application controller processes it, more or less like this:
def account_belongs_to_user(account_id)
account = Account.find(account_id)
return account.user_id==session[:current_user_id]
end
So I guess my security scheme ultimately relies on whether the session data is secure and not trivially spoofable.
b) When I render pages I sometimes pass objects which have senstive data to my erb pages to generate the page text.
For example, I might pass a "company" object (ActiveRecord) to the view to generate an invoice screen. But the company object, passed as #company, has a lot of sensitive data like access keys and the like. Not really being fully aware of the the internals, if I don't specifically include something like:
<%= #company.access_token %>
on my web page, can I be confident that the attributes of #company won't somehow be passed into the browser unless I specifically ask for them to be rendered on the page?
This is obviously an issue when using rails to serve data for say, AngularJS single page applications, as everything I pass for Angular to render the page I assume is probably accessible to an evil-doer even if not on the page itself, but I'm hoping that's not the case with pages generated server side by rails.
This may be a naive question, but thanks as I just want to be certain what I am doing before start spilling secrets all over the place.
put an authentication for the token using active_record callback
https://guides.rubyonrails.org/active_record_callbacks.html
So, I'm trying to set up a React frontend and Rails backend with devise, and the Rails side is supposed to be an internal API. It's the first time I've ever done this, so I'm struggling with authentication. Specifically, in my SessionsController, I have this code:
def create
resource = User.find_for_database_authentication(email: params[:email])
return invalid_login_attempt unless resource
if resource.valid_password?(params[:password])
sign_in :user, resource
return render nothing: true
end
invalid_login_attempt
end
This always returns 401 Unauthorized. I check the result of calling valid_password? and it is always false.
However, if I replace find_for_database_authentication with find_by, the valid_password? works with no problems. Why is this? It's okay if for now the user can only enter his email and not his password, but this really confuses me. It also bugs me that this doesn't use any token checking (different issue).
On the side, I'm also wondering about whether or not CSRF tokens are okay for internal APIs (should I use a different token-auth?), and how I'm supposed to include a CSRF token with a login form if the user isn't logged in yet, but I guess those are questions for another post. Thanks for any help.
I'm trying to set up a blog with Rails and really like Enki www.Enkiblog.com. However, I'm a bit confused about the authentication system it uses with Open Id. On development, it allows you to bypass authentication, but for production it seems to require you to use an OpenId server
I'm hoping to incorporate a simpler authentication system with it, but don't know if that's simpler (I'm a noob) or if it's better to try to figure out how to set up an OpenId server (which requires more installation)
I did look at an Open Id server called Masquerade but it totally confused me. I'm not sure if it's something I try to incorporate with Enki (like a Rails Engine) or if it's a totally separate application.
Any thoughts how I can simplify the authentication, or how it can be simplified so that a noob can use it?
This is the enki.yml file that sets up for OpenId authentication in Enki
# Configuration options for your blog - customise to taste
# This file contains no secret information, so can be stored in source control (unlike database.yml)
title: My Enki Blog
url: http://enkiblog.com
author:
name: Don Alias # For copyright notice and ATOM feeds
email: don#enkiblog.com # Exception emails will go here, and it is used in ATOM feeds
open_id: # These are used to login to the admin area
- http://enkiblog.com
- http://secondaryopenid.com
# Delete the following section if your site will not be acting as an OpenID delegate (http://wiki.openid.net/Delegation)
# If you're deploying with mongrel, make sure you read http://rhnh.net/2008/04/13/nginx-openid-delegation-and-yadis
open_id_delegation:
server: http://www.myopenid.com/server
delegate: http://username.myopenid.com
This is the create action from admin/sessions controller that does that authentication
def create
return successful_login if allow_login_bypass? && params[:bypass_login]
if params[:openid_url].blank? && !request.env[Rack::OpenID::RESPONSE]
flash.now[:error] = "You must provide an OpenID URL"
render :action => 'new'
else
authenticate_with_open_id(params[:openid_url]) do |result, identity_url|
if result.successful?
if enki_config.author_open_ids.include?(URI.parse(identity_url))
return successful_login
else
flash.now[:error] = "You are not authorized"
end
else
flash.now[:error] = result.message
end
render :action => 'new'
end
end
end
All you need is an open id at google (your profile url) or any of the open id providers at openid.net. Once you have found your open id url, all you need to do is open config/enki.yml and change the open-id value to your open id url. e.g.:
open_id: # These are used to login to the admin area
- https://plus.google.com/102381073183096542549
Now to login at admin panel, just enter your profile url. It may ask you to login at your open id provider's site like google.com and then ask for permissions for yourblog.com. Once granted, you will have the admin access. Nobody else will be able to access admin area since you have restricted it to the open_id in enki.yml
You can actually rip out the OpenID Authentication out of Enki by hacking the code. I managed to do this (Rails newbie) so it isn't all that difficult.
The only problem with this being that now you are on your own for updating the Enki code... From what I remember there were quite a few changes that had to be made to accomplish this.