I'm starting to build a really small API and I need to authenticate some endpoints, not all of them. I want to be able to select which endpoint to force authentication with an authenticate! method to be called in the body of the 'route'.
For example:
resource :groups do
desc 'List all groups.'
get do
authenticate!
{ groups: "list of groups v1"}
end
end
I have this working. I used a helper where I manually get the base64 encoded data from the header using: request.env["HTTP_AUTHORIZATION"]. I decode that data and check against the database if the user and secret belongs to a registered user. This is working fine, but I want to use Grape's helper to avoid all the base64 decoding etc etc:
http_basic do |username, password|
end
My idea is inside that method always return true, assign username and password to #username and #password and have a helper that grabs those variables and check against the db. All that works fine, the problem is that for routes that doesn't require authentication as the 'Authorization' header is empty the popup asking for password appears, and I want to avoid that. Is there a way to use the helper to do what I want to do??
BTW: I'm using grape mounted on rails-api
Thanks!
Ok, if I got it right you don't want the username / password box to appear, but instead decide in your code if you actually need the authentication information.
Grape itself uses the default Rack::Auth::Basic class. If you create a customized version of this class you should be able to make your assertions at the beginning of the call method and even pass any other variables to your http_basic block.
You can then add your Authentication strategy to Grape via:
# Add authorization strategy to grape and replace default http_basic
Grape::Middleware::Auth::Strategies.add(:http_basic, Your::Namespace::CustomizedBasicAuth, ->(options) { [options[:realm]] })
This way there is also no need to save the credentials in #username and #password. You could just include or reference the logic inside this authentication strategy.
Nevertheless I somehow would still prefer to split up the API into two parts as Eric already mentioned.
You can break up your Grape::API into multiple modules. Group the modules that need http_basic auth together. Group the modules that don't need http_basic auth separately
Related
So I'm currently in an attempt to make my own account verification system and I'm using some parts of Djoser as a reference. let me try to walk you to my question
Let's say you're to make a new account in Djoser app
you put in the information of your soon to be made account including email
submit the form to the backend
get an email to the whatever email account you put in earlier to verify your account
click the link in your email
get to the verify account page
now in this page there's a button to submit a UID and a token and both of those information lies in the URL.
My question is:
What are those tokens? is it JWT?
How do they work?
How can I implement that in my own projects without djoser?
The answers to your questions are immersed in the own code of djoser.
You can check djoser.email file and in the classes there, they are few methods get_context_data().
def get_context_data(self):
context = super().get_context_data()
user = context.get("user")
context["uid"] = utils.encode_uid(user.pk)
context["token"] = default_token_generator.make_token(user)
context["url"] = settings.ACTIVATION_URL.format(**context)
return context
So get the context in the class where is instance, and in this context add the 'uid' (this is basically str(pk) and coded in base64, check encode_uid()), the 'token' (just a random string created with a Django function from your Secret key; you can change the algorithm of that function and the duration of this token with PASSWORD_RESET_TIMEOUT setting) to use temporary links, and finally the URL according the action which is performed (in this case the email activation).
Other point to consider is in each of this classes has template assigned and you can override it.
Now, in the views, specifically in UserViewSet and its actions perform_create(), perform_update() and resend_activation(), if the Djoser setting SEND_ACTIVATION_EMAIL is True, call to ActivationEmail to send an email to the user address.
def perform_create(self, serializer):
user = serializer.save()
signals.user_registered.send(
sender=self.__class__, user=user, request=self.request
)
context = {"user": user}
to = [get_user_email(user)]
if settings.SEND_ACTIVATION_EMAIL:
settings.EMAIL.activation(self.request, context).send(to)
...
The email is sent and when a user click the link, whether the token is still valid and uid match (djoser.UidAndTokenSerializer), the action activation() of the same View is executed. Change the user flag 'is_active' to True and it may sent another email to confirm the activation.
If you want code your own version, as you can see, you only have to create a random token, generate some uid to identify the user in the way that you prefer. Code a pair of views that send emails with templates that permit the activation.
I have the following model:
class LibraryBook(models.Model):
_name = 'library.book'
name = fields.Char('Title', required=True)
date_release = fields.Date("Release Date")
author_ids = fields.Many2many("res.partner", string="Authors")
I'm new to Odoo and trying to understand the basics of how to save data to my model from a POST request like the following
curl -i -X POST --data "name=Odoo%20-%20Much%20Mystery,%20Wow&author_id=Doge" http://0.0.0.0:8069/test
I found a way doing this by setting the csrf parameter in my controller to false like so:
[...]
#http.route('/test', type='http', auth='public',methods=['POST'], website=True, csrf=False)
def test(self, **kwargs):
record = request.env['library.book'].sudo()
record.create(kwargs)
I'm wondering now if there is a way to avoid setting csrf=false since I've read that it's a bad idea to do so in general. Also, what would I need to get rid of that .sudo()? Not setting csrf=false leads to a 400 BAD REQUEST with Invalid CSRF token. Removing sudo() leads to a 500 INTERNAL SERVER ERROR. In Odoo Development Cookbook it says in one example with auth='none'
Lack of a user is also why we have to sudo() all our calls to model methods in the example code
Assuming I would expect a POST request from an API, is it possible to associate it with a user so I don't have to sudo()?
I would very much appreciate any clarification on this.
UPDATE
So I just found this (line 817):
if the form is accessed by an external third party (e.g. REST API endpoint, payment gateway callback) you will need to disable CSRF
protection (and implement your own protection if necessary) by
passing the csrf=False parameter to the route decorator.
which I guess leaves only one question open, regarding sudo.
SUDO()
creates a new environment with the provided user set, uses the administrator if none is provided (to bypass access rights/rules in safe contexts), returns a copy of the recordset it is called on using the new environment:
Odoo does not allow public users to create, update, delete a record.
If we want to create a record from the public users then we need to create a record with the sudo().
Create record object as administrator
request.env['library.book'].sudo().create(vals)
I hope this may help you.
for more information you can navigate to following links :
https://www.odoo.com/documentation/9.0/reference/orm.html
Thanks
I'm just getting started with Apiary and I can't tell if this is a limitation of the product or just me not understanding what to do.
I'm documenting an API which authenticates the user as part of every request. Sometimes the authentication is part of the path (a request for the user's profile would have the user id in the path), other times just as parameters (?user_id=1&auth=secret), and for POST requests, part of the incoming body as JSON.
Also, there are 3 methods of authentication in the app. You can log in with a Facebook UID, email address, or using the unique id of the device you're using. The result is something that looks like this:
##User [/user/{facebook_uid}{?access_token}, /user/{email}{?device_id}, /users/{device_auth_id}{?device_id}]
This works fine, and displays in the API as I'd expect:
But this introduces 2 issues:
1) If I wanted to add a set of parameters shared by all authentication methods, I would need to add it to all 3 like this:
## User [/user/{facebook_uid}{?access_token, extra_thing, this_too},
/user/{email}{?device_id, extra_thing, this_too},
/users/{device_auth_id}{?device_id, extra_thing, this_too}]
This seems a bit messy, it'd be much nicer to apply shared parameters at the end of the path array so they apply to all, something like this:
## User [/user/{facebook_uid}{?access_token}, /user/{email}{?device_id}, /users/{device_auth_id}{?device_id}]{&extra_thing, this_too}
But this doesn't work. Is there a way to do this? The documentation wasn't very helpful with more complicated stuff like this.
Also, would there be a way to create some kind of template which I could apply to all my methods? In the case where the authentication is part of the path its a bit unavoidable, but for other requests it would be nice to just do something like include: authentication and have it pull the unique_id/auth combo from a defined template somewhere.
Thanks!
First, there isn't really support for having a single model with multiple resource representations. It is an unusual thing to do and is actually good food for thought.
Second, using multiple URIs in [path segment] is probably going to confuse Apiary's mock server and make it unusable.
In my opinion, I'd split this into three models: Facebook User, E-mail User and Device User, with slightly different documentation (how are they created? Can you really create all of them through api? etc. etc.)
It also depends on how you want to document this. As path segments are not validated (it would be strange to have different resources based on the type of the arguments), you can just have (and I'd personally do just that)
## User [/user/{id}{?access_token, extra_thing, this_too}]
+ Parameters
+ id (required, string, `test#example.com`)...id of the user. Can be either user's e-mail, facebook id or device id from where user was created.
As for reusable parts, this is currently being implemented with authentication being part of that.
I'm kind of new to Rails 4. Right now, I'm using both strong params and "normal" params. By normal params I mean the params[:key] which is not permitted.
For example:
Strong params:
def person_params
params.require(:person).permit(:name, :age)
end
And I use both person_params[:name] and params[:key]. Is this going to be problems in the future? what should I do.
You should always use Strong Parameters.
Strong params was created to avoid the issue of Mass Assignment.
This means that if you directly use your params hash, you run into the risk of someone sending a request with parameters they aren't supposed to use and successfully overwrite them in your models.
This means that, for example, someone could gain admin privileges on your site from their "settings" page by maliciously crafting a request that modifies a hypothetical admin attributes in your User model.
Using strong params gives you the guarantee that only the parameters explicitly allowed by you will pass through to the model, so no attacker should be able to bend your application's restrictions.
I am sending email to user, in that email one link is there to redirect that user to rails application. I want that link to be in encrypted form with domain name for example:
https://www.domain_name.com?hdurstihnzdfalgfgdfhdrbnhduolsasrtyumyrtyr
when user click on this link, he should directly redirect to controller method we specified in that URL which is not visible.
Controller and methods given in URL may vary according to user.
So my question is how we can do this in rails.
If I encrypt controller name, method name and parameter we passed. How routes file come to know where to redirect this URL? How to decrypt this in routes file and redirect internally to decrypted URL?
Life will be easier if you can do a slight modification to your url, something like:
https://www.domain_name.com/enc/hdurstihnzdfalgfgdfhdrbnhduolsasrtyumyrtyr
Then you can create a route for that path to redirect where you want.
get '/enc/:encoded_path' => "controller#action"
This would give you access to params[:encoded_path], which would equal hdurstihnzdfalgfgdfhdrbnhduolsasrtyumyrtyr in this case. From there, you could decode in the controller and then redirect however you want.
That's not the right approach. Here's what you can do instead:
Create a new controller action, say for instance, activate.
def activate
activation_token = params[:auth_token]
....
your logic to do whatever with this token
end
Create a corresponding route:
match '/activate' => 'your_awesome_controller#activate'
Now, when you email your users, I'm guessing you're sending some sort of activation token. If not, create two new fields in your users table:
activation_token:string
activated:boolean
Use some unique string generation algorithm to generate your activation_token and email it to your user:
yourdomain.com/activate?auth_token=user.activation_token