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.
Related
I have CAS 6.2.x running in Kubernetes building the image from this repo. I am passing in the cas.properties file via configmap.I have it wired up against Active Directory and am able to login with the Username/Password. I am now working to enable MFA with the Google Authenticator plugin. I have this working as well if I force the flow globally with the following:
cas.authn.mfa.global-provider-id=mfa-gauth
When I try to use the values described here for Multifactor Authentication: Principal Attribute Trigger it doesn't send me to the MFA flow. These are the settings that I have set:
cas.authn.ldap[0].principalAttributeList=userPrincipalName,cn,givenName,sAMAccountName,memberOf
cas.authn.mfa.global-principal-attribute-name-triggers=memberOf
cas.authn.mfa.global-principal-attribute-value-regex=ForceMfa
When I log in these are the values returned back for memberOf:
memberOf
[CN=Group2,OU=MyOu,DC=subdomain,DC=domain,DC=local, CN=Group1,OU=MyOu,DC=subdomain,DC=domain,DC=local, CN=ForceMfa,OU=MyOu,DC=subdomain,DC=domain,DC=local]
Principal
I used Misagh blog post as a guide.
If I change the trigger and regex to sAMAccountName and my username it then works as expected. Not sure if I need to change the regex format to find the group name or if I just have something else wrong. It just seems like the regex is not finding a match for some reason as the settings seem to be working for me, just not with memberOf.
Thank you
Consider switching this to:
cas.authn.mfa.global-principal-attribute-value-regex=.*ForceMfa.+
Then, attach/review your logs for org.apereo.cas under either DEBUG/TRACE so you can see what's happening.
I'm trying to setup a MediaWiki for university students. Using the EmailDomainCheck, I prevent anyone except those with a university based email from creating accounts. Using $wgEmailConfirmToEdit, I can require that an email is confirmed before the user can edit files. However, as it is, a user can use a fake email from the correct domain to create an account. With the account they can view all pages (even though they cannot edit them). I do not want to grant them read access unless the email has been confirmed. Is this possible? Note, I want all confirmed emails of the correct domain to be automatically accepted. It should not require manual account creation acceptance.
You could try the following, as outlined in the Documentation
# Disable for everyone.
$wgGroupPermissions['*']['read'] = false;
# Disable for users, too: by default 'user' is allowed to read, even if '*' is not.
$wgGroupPermissions['user']['read'] = false;
# Make it so users with confirmed email addresses are in the group.
$wgAutopromote['emailconfirmed'] = APCOND_EMAILCONFIRMED;
# Hide group from user list.
$wgImplicitGroups[] = 'emailconfirmed';
# Finally, set it to true for the desired group.
$wgGroupPermissions['emailconfirmed']['read'] = true;
As Jenny Shoars has mentioned, you may wish to whitelist some pages such as:
$wgWhitelistRead = array("Main_Page", "Special:CreateAccount", "Special:ConfirmEmail");
So that non registered users can still create accounts and the like.
In theory,
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['emailconfirmed']['read'] = true;
should work. In practice, MediaWiki almost always used with an "everyone can read" or "you can read iff you are logged in" setup and others are not very well tested, so if that wiki had some highly sensitive private information I wouldn't do this, but I imagine for a university website that's not the case.
Alternatively, it should not be too hard to integrate an email confirmation step into account creation, but you'd have to write the code for that. EmailAuth (which does a similar check during login) might give you an idea of how that would look.
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).
In Box API v1, it was possible to request creation of a shared link for a file or folder, without caring about what kind of sharing was required. In fact, it was not possible to ask for a particular type of share - you just used the public_share method and passed in the target type (file/folder) and target ID, and optionally a share password. In an Enterprise Account, for instance, this might result in the maximum access level being "company" or "collaborators", if public links are disallowed.
With Box API v2, according to the docs here, you need to specify an access parameter that has to be "open", "company", or "collaborators".
The problem is, using the wrong type may cause the share to fail. For instance, in a folder/account that only allows collaborators, I get a 400 error if I ask for a "open" share.
What I really want is to get exactly the same result as if the user clicked the "Share" link in the Box web site. Which is, it should enable sharing for the file but default the level appropriately.
Is there a way to do this with v2, without the admin having to tell us their "preferred" access level for shared links we create? I'm using the Java SDK, like this:
BoxItemRequestObject req = BoxItemRequestObject.createSharedLinkRequestObject(BoxSharedLinkRequestObject.createSharedLinkRequestObject("open"));
BoxItem item = itemsManager.createSharedLink(<ID>, req, BoxResourceType.FILE);
Thanks,
Ben Gilbert
Smartsheet.com
Just set the access to the empty set {}
So your request would look like this:
{"shared_link": {}}
I figured out how to make this work. I need to set access to null when creating the BoxSharedLinkRequestObject, like this:**
BoxItemRequestObject req = BoxItemRequestObject.createSharedLinkRequestObject(BoxSharedLinkRequestObject.createSharedLinkRequestObject(null));
This doesn't produce quite the same JSON as was recommended (shared_link: {}), but it does produce JSON that is apparently equivalent: shared_link: { access: null }. I couldn't figure out any way to produce an empty shared_link object using the SDK -- I either had to have a null shared_link (which didn't work at all) or some value for the access field.
I'm using pas.plugins.sqlalchemy on a fresh new Plone 4.1 installation.
I set Plone to have the email address as login name.
It's all ok, but If I want to change the email address via personal-information panel I obtain an error:
You are not a Plone member. You are probably registered on the root user folder. Please notify an administrator if this is unexpected.
In case I would change another personal data field I don't obtain errors.
The problem seems to be the set_own_login_name function of Products.CMFPlone (utils.py).
Details here http://pastie.org/3780218
Thank's
Vito
Are you logged in as an admin user defined in the Zope root?
If that is the case, then see if you can change the login name by going to the acl_users in the Zope root and changing it there.
Otherwise, temporarily switch off emaillogin, change your email, and switch emaillogin back on.
Note that there is a comment (by me) in the utils.py code right before this KeyError is raised, which points to a possible solution that I don't really like:
# PLIP9214: For a user in the zope root we could do something like this:
# userfolder = member.getUser().__parent__.users
# userfolder.updateUser(member.id, loginname)
# But it is probably best not to touch root zope users.