I'm using Eve framework and I'm trying to use User-Restricted resource access as described in:
http://python-eve.org/authentication.html#user-restricted-resource-access
I'm doing something like:
class CustomAuth(TokenAuth):
def check_auth(self, token, allowed_roles, resource, method):
# Get user as an instance of UserResource.
if user and hasattr(user, 'id'):
self.set_request_auth_value(user['id'])
request.authenticated_user = user
...
So, there are a few question from my side:
Is it enough for using User-Restricted Resource Access?
How this field adds into user created objects?
Is this additional field called id in my user created objects? Is it possible to rename it?
As I understand it should be named same as it's called in User resource. Is it true?
Does this field (property) applies for newly created objects only? Is it possible to fetch previously created objects by current user following this way?
Well, I want to know an answers for my questions + clarify how it may be used.
Is it an expected way to extract it somehow in my hooks?
user_id = current_app.auth.get_request_auth_value()
current_app.data.driver.session.query(resource).find({'id': user_id})
Is this block of code from hook expected?
How it behaves if my requested resource has its own id field?
P.S. I was reading a post:
https://stackoverflow.com/a/35654252/7335432
The user-restricted access feature prevents users from accessing records they didn't create. The set_request_auth_value() method does:
1) Upon making a POST request to create a record, it automatically adds a field specified as AUTH_FIELD (or auth_field if you only want to do it to a specific resource). So for example, if you declare in settings.py
AUTH_FIELD = "my_auth_field"
and then add
set_request_auth_value(user['id'])
to your authentication method, that means that your app creates a field "my_auth_field" that has its value set to whatever user["id"] is. So if you were to go into Mongo Compass or some other DBMS and manually inspect your records, you'd see a "my_auth_field" field in there.
2) On GET requests when you access those records, Eve checks the "my_auth_field" value against whatever user["id"] is, and only displays the records where "my_auth_field" is equal to user["id"]. Since this field is added automatically when you create a record using Eve, it effectively filters out everything that specific user didn't create.
So yes, it only applies to newly created objects. I'm not sure exactly what you mean by "is it enough", but it doesn't look like 'user' is declared anywhere in your authentication class. You might wanna check out this tutorial they do incorporating user restricted access into token authentication.
Related
I'm working with Flask-restplus and I am at a point where I would like to associate each User in my user model to a type of profile, where each user can be associated with one or many profile types. I'm wondering how you guys would go about this. So far, here's what I'm thinking/planning to do. NOTE: I'm not very experienced in web development, so there's a chance I don't know the best way to accomplish this.
Step 1: Create a one-to-many (clients need to also be employees, see below) field (profile_types) relating to a static table that just lists all possible profile options. EXAMPLE:
PK PROFILE TYPE
1 provider
2 employee
3 client
.....
The idea here is to track different information and allow for different views/endpoints for users who are tied to certain profile types. Example, employees would provide a valid login authentication and be directed to page A while a client would be directed to page B, etc. We're also planning on collecting different data points within each profile model.
So an instance of a user might look like this, user1.profile == [client, employee'].
NOTE: This is more important for data collection (ie age of employee, start date, etc) than it is for creating directives based on permissions.
Step 2: Upon creating the new user, a signal fires off the creation of a profile based on the profile_types supplied to the user instance. I've used signals with django in the past, is there a signal library for Flask?
Step 3: An empty profile instance(s) now exists for that user. It will be up to a superuser to upload data in bulk or manually fill out profile information.
Is this a sensible way to go about this? My other though is to create a bunch of Boolean fields in the User model is_provider, is_employee, is_client, etc. All fields that are True get assigned a profile instance. What's the best way to go about this?
Thanks everyone!
Seeing that are you try to validate multiple profile types, you may use
if user.profile_type in ['employee', 'client']
Now, if you want to add an super user I think you can use this
if user.profile_type in ['employee', 'client'] and user.profile_type == 'superuser'
Now, you relationship is more like 'many-to-many', because you are saying that an client also needs to be an employee, if you mean that some endpoints needs to be accessible for employees and clients, then you need to use a 'many-to-one' relationship (an Stackoverflow question which explains what is that)
For your instances, there is Flask Marshmallow, which has an amazing compatibility with Flask SQLAlchemy if you are using an database, but Flask Marshmallow can work alone.
In my Django project I need to access constantly the object of the user`s character(a model), where should I store the value of this object ? since I will be using it in multiple views to display content in the template. Should I store in the session, retrieve from the database every time or some other alternative?
class Character(models.Model):
user = models.OneToOneField(User, on_delete=models.CASCADE,primary_key=True)
gold = models.IntegerField(default=gold)
points = models.IntegerField(default = startPoints)
Not sure what exactly means character, but:
If it is not session-based, but permanent information(and I believe that it is) you need to store it in the database to be able to fetch it when the user log in. How you will store it does not really matter - it can be dedicated table if you need it(in this case would be nice to add user as FK) or it could be a field in User table.
Then, if you have Session middleware and Authentication middleware, you will be able to access user object from the request object, so what you will need to do is:
request.user.character
I hope it is helpful.
UPD: the only way to store the data between requests in DB or caching system(if you have non-DB cache or you don't store session in DB but in something faster instead - like Redis or Memcache). I am adraid that is the only way.
For per-session data you can use cookies in some situation, but I think it isn't the case.
I am designing a new AppEngine/Python HRD application. In this application, I need to ensure that each user that registers cannot use a name that has already been assigned to another user, and that if two users attempt to register with the same username at the exact same moment, that only one of them will be given the username.
If I were to put all usernames in a single entity group and use transactions to ensure uniqueness, then the writing of the username/object in a transaction could potentially slow down all registration processes. So this approach doesn't seem like a good idea.
Another option would be to use the username as the key, which has the disadvantage of possibly making it difficult for the user to later change their username.
What is the best/standard approach to achieve this in AppEngine?
Ok.
You don't need to stick all the usernames in a big entity group to guarantee consistency.
Make the username the Key of the datastore entity governing the login.
Then inside a transaction.
Try a get using the username as a key (this is a consistent operation)
if you find it then obviously it's not available
If not found then create the new login entity.
As an aside if you used email addresses then it would more than likely mean no clashes ever. and I am not sure why visible nick names need to be unique, but then you probably have a good reason.
Each actual user object can have a system generated unique id, (this is a separate entity to the login entity).
If you are really paranoid, then look at using memcache CAS operations to effectively act as a lock on the username key and prevent simultaneous operations, though I don't think it would be necessary.
Entities might look like
class Login(ndb.Model):
# other stuff neede for authentication etc..
user = ndb.KeyProperty(User)
#ndb.transactional(xg=True)
#classmethod
def create_login(cls,username):
# maybe pass in extra user details
key = ndb.Key(cls, keyname)
login = key.get()
if login:
raise DuplicateUsernameError(username)
login = Login(key_name=username)
user = User.create_user(login=login.key)
login.user = user.key
login.put()
return (login,user)
class User(ndb.Model):
login = ndb.KeyProperty(Login) # this property is only for convenience.
nickname = ndb.StringProperty()
# etc
#classmethod
def create_user(cls,login_key):
# yes you would pass in more user stuff.
user = cls(login=login_key)
user.put()
# the unique user key is system generated.
return user
This means only a single get() is required to fetch a login, and second to get the rest of the user details but is much cheaper/faster than queries. It also means that the login name/code could be changed over time without disrupting the actual user entity if you really wanted such functionality. Or possibly support multiple login methods for a single user - ie facebook and twitter. It also means a login entity can be removed and login re-used by other people over time, and the user entity can stay if system integrity/history is required.
App Engine allows up to 1 write per second within the same entity group. To surpass that barrier you have to have 60 x 60 x 24 = 86.4k registrations on the same day, which I think you can live with.
If you still think you need any faster process you could use sharding (more typically known for counters - https://developers.google.com/appengine/articles/sharding_counters), which is basically having different tables for users (or usernames) so that you can read them all to check for uniqueness (App Engine is good at doing many reads per second) and have as much better write pace as tables for usernames you add.
More of sharding on writes here - https://developers.google.com/appengine/articles/scaling/contention
Hope it helps.
I'm working on a project,
this project must have many users, each user can create for examples many support tickets and he could see them and edit them, but he is not allowed to access any other ticket, which not belong to him
so for example :
def edit_ticket():
record = db.e_ticket(request.args(0),active=True) or redirect(URL('error'))
form=crud.update(db.e_ticket,record,next='view_ticket/[id]')
return dict(form=form)
in this way with (request.args(0)) the user can edit every ticket in the system just to change the id to any other id and it will work
edit_ticket/[id]
so i changed the request.args(0) with auth.user_id, it was a great solution as i thought! but when we've many users so only the 1st and 2ed user could edit this thier tickets the next users cannot do that and receive an error when they do this "edit_Ticket/[id]"
Error the document doesn't exist
what should i do to prevent users from bypassing their privilege
Regards
it shouldn't be:
db.e_ticket(request.args(0),user_id==auth.user_id,active==True)
but
db.e_ticket(request.args(0),user_id=auth.user_id,active=True) -
because here we're passing function arguments and not query conditions
web2py has buildin user access control. please reference the web2py book:
users should login to edit their ticket, so you can use #auth.requires_login() to decorate edit_ticket(). In edit_ticket() you can check whether the user_id has the ticket_id first.
Maybe look into using authorization and CRUD (and generally how to set permissions on particular database records).
Note, you can't replace request.args(0) with auth.user_id. request.args(0) is referring to the id of the e_ticket record, not the user id. If the e_ticket table includes a field referencing the user id (e.g., e_ticket.user_id), then you could add user_id=auth.user_id as a condition.
next='view_ticket/[id]'
You should use the URL() function to create URLs -- URL(f='view_ticket',args=[id]). Also, what is [id] supposed to be -- I don't see any reference to id in the code?
I'm trying to selectively process a field in my Django/Python application based on whether a user is logged in or not. Basically, I have a model similar to the following:
class Resource(models.Model):
uploaded = models.DateTimeField()
name = models.CharField(max_length=200)
description = models.CharField(max_length=500, blank=True)
file = models.CharField(max_length=200)
What I want to do is for the file attribute to be set to one value if the user happens to be logged in (and has access to this resource based on a test against some permissions backend), and another value if the user is not logged in. So, when any client code tries to access Resource.file, it will get something like the following if the user is not logged in 'http://mysite.com/dummy_resource_for_people_without_access'. However, if the user is logged in and passes some tests for permissions, then the value of resource.file will actually be the true url of that resource (including any security keys etc. to access that resource).
From what I've read, it seems that you can only take account of the currently logged in user by passing that through the request context from a view function to the model. However, in the above use case I am trying to control the access more closely in the model without needing the client code to call a special function.
Your best bet is to create a function used to access the file attribute, and check there. In general, it would possible to turn the attribute into a descriptor which does it implicitly, but Django's metaclass magic would impede that.
In general however, Django is designed to handle authentication at the view-level (and does it very cleanly). If you need database layer authentication, consider a different setup, such as CouchDB.
Just in case anyone's interested, I solved the above issue by actually creating a custom model field in django that could then have a method that takes a user to generate a URI. So, in the database, I store a key to the resource as above in the file column. However, now the file column is some custom field:
class CustomFileField(models.CharField):
def to_python(self, value):
...
return CustomFileResource(value)
class CustomFileResource:
def __init__(self, *args, **kwargs):
....
def uri(usr):
#this method then gets the uri selectively based on the user .
The pattern above is nice because I can wrap the db field and then create a specific method for getting the uri based on who is trying to access it.