I would like to automatically create some objects instance when a new user is created. I think using signals would be the best strategy but it seems there is no signal attached to user creation.
I am also using django-registration, but I would prefer using signals on user creation rather than on user registration.
What is the best approach for such purpose?
Related
I am kind of new to aws amplify and I don't understand where I can create a new mutation of type "create".
I would like to do the following:
I have one house model (GraphQL) that has a name and can have multiple people assigned to it (one to many).
When I create the house, I want to automatically assign the user who is connected (cognito) to be the owner of the house. From the serverside so on the mutation because i don't want to assign this in the api call since it could be modified.
Any tips where I can create this mutation or a link to a tutorial on how to accomplish this?
For a little backstory, we're currently in the middle of migrating a Cognito user pool to a new one, due to several outdated configuration properties we need to update. To do this, we are planning on using a Cognito Lambda trigger to handle the migration.
However, the big problem we're running into is that we use the sub attribute as an ID for the user. According to AWS, this value is globally unique across all user pools. This means that we cannot migrate the sub attribute to a new pool, since it would then no longer be unique.
According to this question and answer, they indicate that the sub attribute is the correct attribute to use for a primary key. However, in the event of a disaster like a deleted or corrupted pool, using the sub attribute as a primary key doesn't work. If you import users to a backup pool, the sub's will be different and your primary key will be lost.
At this point, I should mention that we are using the Access token for the "groups", which does not contain any custom attributes, so adding the primary key to the custom attributes doesn't work for us.
So to finally get to my question, what should we be using for a primary key with AWS Cognito so we don't run into this pitfall again?
In django-webtest, every test TestCase subclass comes with self.app, which is an instance of webtest.TestApp, then I could make it login as user A by self.app.get('/',user='A').
However, if I want to test the behavior if for both user A and user B in a test, how should I do it?
It seems that self.app is just DjangoTestApp() with extra_environ passed in. Is it appropriate to just create another instance of it?
I haven't tried setting up another instance of DjangoTestApp as you suggest, but I have written complex tests where, after making requests as user A I have then switched to making requests as user B with no issue, in each case passing the user or username in when making the request, e.g. self.app.get('/', user'A') as you have already written.
The only part which did not work as expected was when making unauthenticated requests, e.g. self.app.get('/', user=None). This did not work as expected and instead continued to use the user from the request immediately prior to this one.
To reset the app state (which should allow you to emulate most workflows with several users in a sequential manner) you can run self.renew_app() which will refresh your app state, effectively logging the current user out.
To test simultaneous access by more than one user (your question does not specify exactly what you are trying to test) then setting up another instance of DjangoTestApp would seem to be worth exploring.
I need to store full history of changes made to objects. I find django-simple-history very appealing but it does not work with django-tastypie. If I send data to API using PUT (update the object), the object is updated OK but the history records are not updated. If I change the objects manually via './manage.py shell' everything works fine. It looks like tastypie is bypassing signals or something.
Any ideas how I could get this to work as expected?
Without seeing your code I'm going to attempt to solve this one analytically.
Looking at django-simple-history it seems the project does indeed create history objects on post_save/post_delete signals and provides access to them using a custom model.Manager subclass.
It looks to me that the resource that TastyPie saves is a ModelResource and not your actual Model instance. This proxy model is aware of the orm and performs all the queries on it.
So what I think happens in simple_history/models.py is that contribute_to_class method declares models.signals.class_prepared.connect(self.finalize, sender=cls) but this signal never fires since TastyPie does not initialize an instance of the model...
This seems so strange and I cannot understand why TastyPie does that, or maybe I'm misunderstanding something? Why don't you try to open an issue in the github repo?
Using tastypie, how do I only authorize authors of objects the ability to edit/delete objects they have created? For example, if user 1 created an object A, how can I make it so user 2 cannot edit or delete object A but user 1 can edit or delete object A?
Check this cook-book entry:
http://django-tastypie.readthedocs.org/en/latest/cookbook.html#creating-per-user-resources
If that doesn't fit you well, there is an WIP on per-object permissions in the perms branch of tastypie repo. You might want to check that out but beware that it's not ready yet.