Examples of org.apache.jackrabbit.core.security.user.UserManagerImpl$NodeCreator

Package org.apache.jackrabbit.core.security.user

Examples of org.apache.jackrabbit.core.security.user.UserManagerImpl$NodeCreator

org.apache.jackrabbit.core.security.user.UserManagerImpl
Inner class creating the JCR nodes corresponding the a given authorizable ID with the following behavior:
- Users are created below /rep:security/rep:authorizables/rep:users or the corresponding path configured.
- Groups are created below /rep:security/rep:authorizables/rep:groups or the corresponding path configured.
- Below each category authorizables are created within a human readable structure based on the defined intermediate path or some internal logic with a depth defined by the defaultDepth config option.
  E.g. creating a user node for an ID 'aSmith' would result in the following structure assuming defaultDepth == 2 is used:
```
 + rep:security            [nt:unstructured] + rep:authorizables     [rep:AuthorizableFolder] + rep:users           [rep:AuthorizableFolder] + a                 [rep:AuthorizableFolder] + aS              [rep:AuthorizableFolder] ->        + aSmith        [rep:User] 
```
- In case of a user the node name is calculated from the specified UserID {@link Text#escapeIllegalJcrChars(String) escaping} any illegal JCR chars.In case of a Group the node name is calculated from the specified principal name circumventing any conflicts with existing ids and escaping illegal chars.
- If no intermediate path is passed the names of the intermediate folders are calculated from the leading chars of the escaped node name.
- If the escaped node name is shorter than the defaultDepth the last char is repeated.
  E.g. creating a user node for an ID 'a' would result in the following structure assuming defaultDepth == 2 is used:
```
 + rep:security            [nt:unstructured] + rep:authorizables     [rep:AuthorizableFolder] + rep:users           [rep:AuthorizableFolder] + a                 [rep:AuthorizableFolder] + aa              [rep:AuthorizableFolder] ->        + a             [rep:User] 
```
- If the autoExpandTree option is true the user tree will be automatically expanded using additional levels if autoExpandSize is exceeded within a given level.
The auto-expansion of the authorizable tree is defined by the following steps and exceptional cases:
- As long as autoExpandSize isn't reached authorizable nodes are created within the structure defined by the defaultDepth. (see above)
- If autoExpandSize is reached additional intermediate folders will be created.
  E.g. creating a user node for an ID 'aSmith1001' would result in the following structure:
```
 + rep:security            [nt:unstructured] + rep:authorizables     [rep:AuthorizableFolder] + rep:users           [rep:AuthorizableFolder] + a                 [rep:AuthorizableFolder] + aS              [rep:AuthorizableFolder] + aSmith1       [rep:User] + aSmith2       [rep:User] [...] + aSmith1000    [rep:User] ->        + aSm           [rep:AuthorizableFolder] ->          + aSmith1001  [rep:User] 
```
- Conflicts: In order to prevent any conflicts that would arise from creating a authorizable node that upon later expansion could conflict with an authorizable folder, intermediate levels are always created if the node name equals any of the names reserved for the next level of folders.
  In the example above any attempt to create a user with ID 'aSm' would result in an intermediate level irrespective if max-size has been reached or not:
```
 + rep:security            [nt:unstructured] + rep:authorizables     [rep:AuthorizableFolder] + rep:users           [rep:AuthorizableFolder] + a                 [rep:AuthorizableFolder] + aS              [rep:AuthorizableFolder] ->        + aSm           [rep:AuthorizableFolder] ->          + aSm         [rep:User] 
```
- Special case: If the name of the authorizable node to be created is shorter or equal to the length of the folder at level N, the authorizable node is created even if max-size has been reached before.
  An attempt to create the users 'aS' and 'aSm' in a structure containing tons of 'aSmith' users will therefore result in:
```
 + rep:security            [nt:unstructured] + rep:authorizables     [rep:AuthorizableFolder] + rep:users           [rep:AuthorizableFolder] + a                 [rep:AuthorizableFolder] + aS              [rep:AuthorizableFolder] + aSmith1       [rep:User] + aSmith2       [rep:User] [...] + aSmith1000    [rep:User] ->        + aS            [rep:User] + aSm           [rep:AuthorizableFolder] + aSmith1001  [rep:User] ->          + aSm         [rep:User] 
```
- Special case: If autoExpandTree is enabled later on AND any of the existing authorizable nodes collides with an intermediate folder to be created the auto-expansion is aborted and the new authorizable is inserted at the last valid level irrespective of max-size being reached.
The configuration options:
- defaultDepth:
  A positive integer greater than zero defining the depth of the default structure that is always created.
  Default value: 2
- autoExpandTree:
  boolean defining if the tree gets automatically expanded if within a level the maximum number of child nodes is reached.
  Default value: false
- autoExpandSize:
  A positive long greater than zero defining the maximum number of child nodes that are allowed at a given level.
  Default value: 1000
  NOTE: that total number of child nodes may still be greater that autoExpandSize.

            log.debug("No anonymousID defined in LoginModule/JAAS config -> using default.");
            anonymousId = SecurityConstants.ANONYMOUS_ID;
        }


        // create the system userManager and make sure the system-users exist.
        systemUserManager = new UserManagerImpl(securitySession, adminId);
        createSystemUsers(systemUserManager, adminId, anonymousId);


        // init default ac-provider-factory
        acProviderFactory = new AccessControlProviderFactoryImpl();
        acProviderFactory.init(securitySession);

View Full Code Here

        } else if (session instanceof SessionImpl) {
            String workspaceName = securitySession.getWorkspace().getName();
            try {
                SessionImpl sImpl = (SessionImpl) session;
                SessionImpl s = (SessionImpl) sImpl.createSession(workspaceName);
                return new UserManagerImpl(s, adminId);
            } catch (NoSuchWorkspaceException e) {
                throw new AccessControlException("Cannot build UserManager for " + session.getUserID(), e);
            }
        } else {
            throw new RepositoryException("Internal error: SessionImpl expected.");

View Full Code Here

            return systemUserManager;
        } else if (session instanceof SessionImpl) {
            String workspaceName = systemSession.getWorkspace().getName();
            try {
                SessionImpl sImpl = (SessionImpl) session;
                UserManagerImpl uMgr;
                if (workspaceName.equals(sImpl.getWorkspace().getName())) {
                    uMgr = createUserManager(sImpl);
                } else {
                    SessionImpl s = (SessionImpl) sImpl.createSession(workspaceName);
                    uMgr = createUserManager(s);

View Full Code Here


        // since users are stored in and retrieved from a dedicated workspace
        // only the system session assigned with that workspace will get the
        // system user manager (special implementation that asserts the existance
        // of the admin user).
        UserManagerImpl um;
        if (umc != null) {
            Class<?>[] paramTypes = new Class[] { SessionImpl.class, String.class, Properties.class };
            um = (UserManagerImpl) umc.getUserManager(UserManagerImpl.class, paramTypes, (SessionImpl) session, adminId, params);
            // TODO: should we make sure the implementation doesn't allow
            // TODO: to change the autosave behavior? since the user manager
            // TODO: writes to a separate workspace this would cause troubles.
        } else {
            um = new UserManagerImpl(session, adminId, params);
        }
        return um;
    }

View Full Code Here

     * @throws RepositoryException
     */
    @Override
    protected UserManagerImpl createUserManager(SessionImpl session) throws RepositoryException {
        UserManagerConfig umc = getConfig().getUserManagerConfig();
        UserManagerImpl umgr;
        // in contrast to the DefaultSecurityManager users are not retrieved
        // from a dedicated workspace: the system session of each workspace must
        // get a system user manager that asserts the existence of the admin user.
        if (umc != null) {
            Class<?>[] paramTypes = new Class[] {
                    SessionImpl.class,
                    String.class,
                    Properties.class,
                    MembershipCache.class};
            umgr = (UserPerWorkspaceUserManager) umc.getUserManager(UserPerWorkspaceUserManager.class,
                    paramTypes, session, adminId, umc.getParameters(), getMembershipCache(session));
        } else {
            umgr = new UserPerWorkspaceUserManager(session, adminId, null, getMembershipCache(session));
        }


        if (umc != null && !(session instanceof SystemSession)) {
            AuthorizableAction[] actions = umc.getAuthorizableActions();
            umgr.setAuthorizableActions(actions);
        }
        return umgr;
    }

View Full Code Here

    Properties tenantProperties = new Properties();
    tenantProperties.put( UserManagerImpl.PARAM_USERS_PATH, UserManagerImpl.USERS_PATH
        + theTenant.getRootFolderAbsolutePath() );
    tenantProperties.put( UserManagerImpl.PARAM_GROUPS_PATH, UserManagerImpl.GROUPS_PATH
        + theTenant.getRootFolderAbsolutePath() );
    return new UserManagerImpl( (SessionImpl) session, session.getUserID(), tenantProperties );
  }

View Full Code Here

            if (clName != null && !(UserManagerImpl.class.getName().equals(clName) || clName.length() == 0)) {
                log.warn("Unsupported custom UserManager implementation: '" + clName + "' -> Ignored.");
            }
            config = umc.getParameters();
        }
        return new UserManagerImpl(session, adminId, config);
    }

View Full Code Here

            return systemUserManager;
        } else if (session instanceof SessionImpl) {
            String workspaceName = securitySession.getWorkspace().getName();
            try {
                SessionImpl sImpl = (SessionImpl) session;
                UserManagerImpl uMgr;
                if (workspaceName.equals(sImpl.getWorkspace().getName())) {
                    uMgr = createUserManager(sImpl);
                } else {
                    SessionImpl s = (SessionImpl) sImpl.createSession(workspaceName);
                    uMgr = createUserManager(s);

View Full Code Here

            return systemUserManager;
        } else if (session instanceof SessionImpl) {
            String workspaceName = systemSession.getWorkspace().getName();
            try {
                SessionImpl sImpl = (SessionImpl) session;
                UserManagerImpl uMgr;
                if (workspaceName.equals(sImpl.getWorkspace().getName())) {
                    uMgr = createUserManager(sImpl);
                } else {
                    SessionImpl s = (SessionImpl) sImpl.createSession(workspaceName);
                    uMgr = createUserManager(s);

View Full Code Here


        // since users are stored in and retrieved from a dedicated workspace
        // only the system session assigned with that workspace will get the
        // system user manager (special implementation that asserts the existence
        // of the admin user).
        UserManagerImpl um;
        if (umc != null) {
            Class<?>[] paramTypes = new Class[] {
                    SessionImpl.class,
                    String.class,
                    Properties.class,
                    MembershipCache.class};
            um = (UserManagerImpl) umc.getUserManager(UserManagerImpl.class,
                    paramTypes, session, adminId, params, getMembershipCache(session));
            // TODO: should we make sure the implementation doesn't allow
            // TODO: to change the autosave behavior? since the user manager
            // TODO: writes to a separate workspace this would cause troubles.
        } else {
            um = new UserManagerImpl(session, adminId, params, getMembershipCache(session));
        }


        if (umc != null && !(session instanceof SystemSession)) {
            AuthorizableAction[] actions = umc.getAuthorizableActions();
            um.setAuthorizableActions(actions);
        }
        return um;
    }

View Full Code Here

0 1 2 3

TOP

Related Classes of org.apache.jackrabbit.core.security.user.UserManagerImpl$NodeCreator

org.apache.jackrabbit.api.security.user.Authorizable

org.apache.jackrabbit.api.security.user.Group

org.apache.jackrabbit.api.security.user.User

org.apache.jackrabbit.api.security.user.UserManager

org.apache.jackrabbit.core.DefaultSecurityManager

org.apache.jackrabbit.core.id.NodeId

org.apache.jackrabbit.core.NodeImpl

org.apache.jackrabbit.core.security.principal.PrincipalImpl

org.apache.jackrabbit.core.UserPerWorkspaceSecurityManager

org.apache.jackrabbit.spi.Name

All source code are property of their respective owners. Java is a trademark of Sun Microsystems, Inc and owned by ORACLE Inc. Contact coftware#gmail.com.