Bug 37732

Summary: Resource Locks Aren't Persisted Using LDAP
Product: Slide Reporter: Damien Bastin <damien.bastin>
Component: StoresAssignee: Slide Developer List <slide-dev>
Status: NEW ---    
Severity: normal    
Priority: P2    
Version: Nightly   
Target Milestone: ---   
Hardware: PC   
OS: Windows 2000   
Attachments: Inserts URI into DB when putLock() called

Description Damien Bastin 2005-12-01 08:20:04 UTC
Locks on resources are lost when you restart the WebDAV server if you dont store
user info in the database. 

The lock table is not being written to by when using LDAP for user information.
This is because the insert command in the StandardRBDMSAdapter checks for users
in the slide database. 

When you are using an external source for users and roles (i.e. LDAP) there is
nothing stored in the database except for what is defined in the Domain.xml.

This problem may effect other parts of the system including LINKS, LABELs and
potentially ACLs.

To reproduce the problem:

    * Log into WebDAV as a user in LDAP store.
    * Use a WebDAV client to lock a resource.
    * Restart WebDAV server.
    * Refresh the view, the resource will be unlocked. 

To fix the problem:

    * Insert /users/support into the WebDAV URI table.
    * Log into WebDAV.
    * Use a WebDAV client to lock a resource.
    * Restart WebDAV server.
    * Refresh the view, the resource will be locked. 

Here is the solution in code. You can change the StandardRDBMSAdapter like so:

public void putLock(Connection connection, Uri uri, NodeLock lock) throws
ServiceAccessException {
        PreparedStatement statement = null;
        try {
            int inheritable = lock.isInheritable() ? 1 : 0;
            int exclusive = lock.isExclusive() ? 1 : 0;
            long lockid = assureUriId(connection, lock.getLockId());

            populateUriTableWithUserUri(connection, lock);

            statement = connection.prepareStatement(
                    "insert into LOCKS
(LOCK_ID,OBJECT_ID,SUBJECT_ID,TYPE_ID,EXPIRATION_DATE,IS_INHERITABLE,IS_EXCLUSIVE,OWNER)
" +
                    "select ?, object.URI_ID, subject.URI_ID, type.URI_ID, ?, ?,
?, ? " +
                    "from URI object, URI subject, URI type WHERE
object.URI_STRING=? and subject.URI_STRING=? and type.URI_STRING=?");
            statement.setLong(1, lockid);
            statement.setLong(2, lock.getExpirationDate().getTime());
            statement.setInt(3, inheritable);
            statement.setInt(4, exclusive);
            statement.setString(5, lock.getOwnerInfo());
            statement.setString(6, lock.getObjectUri());
            statement.setString(7, lock.getSubjectUri());
            statement.setString(8, lock.getTypeUri());

            statement.execute();
            if (statement.getUpdateCount() == 0) {
                throw new ServiceAccessException(service, "Insert of the lock
failed as the user could not be found in the URI table.");
            }
        } catch (SQLException e) {
            throw createException(e, uri.toString());
        } finally {
            close(statement);
        }
    }

    private void populateUriTableWithUserUri(Connection connection, NodeLock
lock) throws SQLException {
        PreparedStatement statement = connection.prepareStatement("select URI_ID
from URI where URI_STRING = ?");
        statement.setString(1, lock.getSubjectUri());
        statement.execute();
        ResultSet results = statement.getResultSet();
        boolean hasNextRow = results.next();
        if (hasNextRow == false) {
            insertUri(connection, lock.getSubjectUri());
        }
    }

    private void insertUri(Connection connection, String subjectUri) throws
SQLException {
        PreparedStatement statement = connection.prepareStatement("Insert into
URI (URI_STRING) values (?)");
        statement.setString(1, subjectUri);
        statement.execute();
    }

END OF DOCUMENTATION
Comment 1 Damien Bastin 2005-12-01 08:24:07 UTC
Created attachment 17100 [details]
Inserts URI into DB when putLock() called

Note that this attachment also contains the fix to bug id: 37583