I have a custom permission model for my project and I'm not using django's default permissions backend. I have a custom has_permission template tag to check if the user has the specified permission or not.
The problem is that there's lots of queries done for the same checks every time, I'm looking for a way to reduce my Permission queries. What I'm doing inside my templates is like :
{% if user|has_permission:'jpermission.can_edit_jpermission' or
user|has_permission:'jgroup.can_edit_jgroup' or
user|has_permission:'role.can_edit_role' %}
and the code for has_permission template tag is as follows :
rep = perm_name.split('.') # rep is for e.g. "jpermission.can_edit_jpermission"
ctn_type = rep[0]
codename = rep[1]
pr = JPermission.objects.filter(model_name=ctn_type, codename=codename)
if pr.exists():
if user.has_perm(pr[0]):
return True
Specifically talking, the problem is that every time i check even for the exactly same if statements, lots of queries are made (from what I'm doing, it's obvious there will be).
Is there any other way i can go at it ? like query all permissions once, cache them, and do something like how prefetch_related is handled to prohibit further db queries (python filtering with loops and ... ) ?
P.S: has_perm is also overridden and checks if users role, group or permissions have the specified permission or not)
There are multiple solutions for this.
Move permissions to user model as methods of model and use cached_property decorator so that consecutive calls to methods does not hit database again.
Store the permissions state in session when user logged in, and later use session data to check for permissions.
It looks like you are using django-guardian, and it is already caching the permissions:
Once checked for single object, permissions are stored and we don’t
hit database again if another check is called for this object. This is
great for templates, views or other request based checks (assuming we
don’t have hundreds of permissions on a single object as we fetch all
permissions for checked object).
Related
this question has been posed in many flavours, but no one fits my needs.
I'm working on a partially complete Razor project; the original developer has left our office, and he wasn't much concerned about securing password fields, as he left all of them in clear.
These passowrd fields authorize several aspects (Ftp primary and secondary access, Ftp on AS400 and mail sending), so nothing related with login/submit forms. When I changed these fields from text to password, they revert to blank fields, regardless the content of the View Model, and this should be the correct behaviour, as per the numerous answers I've seen googlin around.
My problem is this: the user needs to know at least if a password has been configured (seeing a string of * or any other mask character the browser use), so I need to show him that value to let him know if the service is configured, and the best would be to let him also reveal the password to check if it's correct. The option to not update the particular field in the DB if it's left blank is not an option.
This site works only on Intranet, so there is no concern about hackers monitoring the connection or similar.
I've tried all (I think) the possible combinations, including building the input element manually through html, using the #Html.TextFor and #Html.PasswordFor helpers, decorating the corrisponding member in the view model with [DataType(DataType.Password)]. The data is binded when the page is loaded, so no ajax calls help me retrieving data.
I'm relatively new to Razor, as my last two projects are entirely in PHP.
Thanks for any suggestions.
Ok, no other solution found than issuing an ajax call to a dedicated HttpGet controller method to retrieve only the password fiels, then populating the dedicated fields when the controller returns the object containing all the password I need.
I'm making a web app where users can create pages, edit them, and delete them. In developing the prototype, I have a user access a route such as:
localhost:8000/mypage/1
The "1" in the URL refers to the ID in the database, so that the controller can fetch the appropriate associated data and populate the page accordingly.
The obvious problem here is that a user can plug in any number to that URL and edit someone else's page.
One obvious fix would be to add logic that checks whether or not page '1' belongs to the Auth::user(). But this would be an if statement that I have to add to every controller that carries out such function.
When I think about other sites, they never have ID's in the URL, or if they do, they look 'encrypted' in some form. What is the best practice for changing an ID into some uninterpretable string that I frequently see done on other websites?
Thank you for any help.
why don't you just use a middleware that check if the route can be acceded by the user? then you can call it with
$this->middleware('middlewareName');
in the controller that you need it or even in the web.php if you want a whole set of routes protected
I made OnBeforeinitialize hook. I need place there code which register new user if user doesn't exists in database.
Which MediaWiki class and functions should be used?
If you need to create users, chances are you are doing something wrong. Users should be created on login/signup (use a PrimaryAuthenticationProvider to tell the system to create them), or when they are authenticated based on request data (use a SessionProvider). There is also User::newSystemUser but it's only meant for scripts.
Even if I don't know, what you really want to do, where the data for the user should came from, and why you want to do this in the BeforeInitialize hook (so, in fact, any useful information to really know and understand what you want to achieve is missing, therefore, you'll get an answer to your concrete question without any guarantee, that it works like you expected in your use case). However, to create a new user, you can use the createNew function of the User class. You should check, if the user is already present in the database.
EDIT:
An usage example:
$user = User::createNew( 'Testuser', [ 'email' => 'email_from#external_source.com' ] );
I'm currently working on a platform which is planned to coordinate the communication with customers in future. Users can be added to projects and have certain rights. Therefore users are assigned to different user roles (admin/manager/member/viewer). Admins can view all projects and are allowed to add other users to a project. If a user (e.g. role:member) is added to a project, he will have certain rights (depending on the role), if not, he is not allowed to access the project at all.
I'm using Cake's ACL Component and everything is working great, when i disregard if a user is added to a project or not. The only solution I can think of, is not to grant rights on the group-level, but on the user-level when an admin adds an user to the project.
Is there an easier way to solve this issue? Otherwise I'm afraid that the code would become totally confusing.
There is a another way (I don't really know if easier, depends on your point of view). The ACL component only helps you to create roles, but you need a role and project-access management, right?
What I do in this cases:
Create a Project_Permission table in your database (give it a better name, I'm lacking imagination). Depending on your project, create the associations: a user can be related to many projects and a project can have many users accesing it. If you are following the cake conventions (and your tables are named users and projects) and it doesn't interfere with what you already have, the table should be
PROJECTS_USERS
id
project_id
user_id
created and modified //if you want to
Create appropriate actions where the admin (or other type if users, that's up to you)
can add users to projects and save that many-to-many association in
the previously created table.
Since the authorization for the project does not come from the ACL component, you have to create an "authorization" function yourself. I recommend putting this in the beforeFilter() function of the AppController (if you don't have an AppController, you'll have to do it in every controller you want this to work). In this function, check if the logged user is in the existing table and has an association with the project. Something like:
function beforeFilter() {
//let's assume you have the project id somewhere, in a global variable like $this->_projectID
$user = $this->Session->read('Auth.User.id');
$project = $this->Project->find('first', array('conditions'=>array('id'=>$this->_projectID, 'User.id'=>$user)
if (count($project) > 0) {
//the user has permission to see the project
} else {
//he doesn't
}
}
It's difficult to give an actual code because I'm not sure of your model associations nor where do you want the code or if you have the variables needed for this available everywhere, but I hope you get the idea. After that it's just a matter of how you want to handle the restriction of access (normally a flash message and redirection is involved).
I hope this is clear enough :S
I'm checking if this is a sitecore bug, or if I'm missing something obvious.
EDIT FOR CLARIFICATION: The problem I'm having is that I'm trying to set up the configuration settings in the Domains.config file so that Sitecore shouldn't be creating (and/or returning) an anonymous user for a domain set up this way. However, if I use the Domain.GetUsers() function on the domain, I still get the anonymous user returned.
The membership provider is a custom built and connects to LDAP in read only mode.
Details
Using Sitecore 6.4.1 and given the following domain configuration in App_Config/Security/domains.config
<domain name="DOMAINNAME" ensureAnonymousUser="false" anonymousUserName="" everyoneRoleName="" />
and these comments in that domain.config file
anonymousUserName: <snip> Set to blank to disable the anonymous user for the domain. Optional
ensureAnonymousUser: Indicates if the domain should ensure that an anonymous user for the domain exists in the Membership database. Optional - default value: false
everyoneRoleName: <snip> Set to blank to disable the everyone role for the domain. Optional - default value: Everyone
If I use the following code,
List<Sitecore.Security.Accounts.User> users = new List<Sitecore.Security.Accounts.User>();
var domain = Sitecore.Security.Domains.Domain.GetDomain(DOMAINNAME);
users.AddRange(domain.GetUsers().ToArray<Sitecore.Security.Accounts.User>());
I get the anonymous user included in users list. I assumed from the comments in the domain.config file that I shouldn't get the anonymous user if I set up my domain as above.
Is there something obvious that I'm missing?
Just a guess as I have not used 6.4 yet or tweaked any of those types of setting before... but I believe Sitecore always comes pre-packaged with the Anonymous user in the membership. By setting ensureAnonymousUser to false you're just telling it not to ensure its there, but its already there by default. Why don't you try this test:
Set ensureAnonymousUser to true then delete [*] the Anonymous user from the user manager.
Log out and back in and see if it's there again. If so then the "ensure" aspect of that worked. So...
Set ensureAnonymousUser to false then do the same thing. Does the user come back?
This is really just a hunch on how it works -- I don't have an environment like that setup right now to play with, but its worth a shot.
[*] - to delete a user form the User Manager, go to Sitecore > Security > User Manager
I think it's more question to membership provider you use. Take a look at Active Directory Module
Maybe this is something that could help you.