Can you have a look at the database and check whether the permissions you set are stored there (in table PERMISSIONS I think). Stefan
Jussi Vaihia wrote:
Actually it seems restarting Tomcat kills all the ACLs (throughout Slide) that have been set in this manner -- that is, directories and files that have (Subject) "all" set on them with no other permissions. It does not, however, touch ACL's that are set with (Subject) "/users/.../" or "/roles/.../" and perhaps as well if these are combined with (Subject) "all".
Any suggestions on how to fix this and have these permissions as permanent as those with roles/users?
On Fri, 22 Oct 2004 13:22:13 +0200, Stefan L�tzkendorf <[EMAIL PROTECTED]> wrote:
Jussi Vaihia wrote:
That is a good question. Knowing this would help narrow down the cause. I haven't been able to determine a repetitive pattern.
Does Slide ever tamper with the ACLs on its own at any given point?
Not that I know of. May be it is related to caching. You could disable caching by setting <parameter name="cache-mode">off</parameter> on your store. It will be somewhat slower than, but would eleminate this option.
On Fri, 22 Oct 2004 11:18:38 +0200, Stefan L�tzkendorf <[EMAIL PROTECTED]> wrote:
Hmmm, there seems to be nothing wrong. I just wonder at the "memory" name of your store (I use this name always with transient sores). I have no real idea. What are you doing until the permissions are lost? Havy work of just waiting?
Stefan
Jussi Vaihia wrote:
Here you go:
<slide> <namespace name="slide"> <definition> <store name="memory"> <nodestore classname="org.apache.slide.store.impl.rdbms.JDBCStore"> <parameter name="adapter">org.apache.slide.store.impl.rdbms.MySqlRDBMSAdapter</parameter> <parameter name="user">user</parameter> <parameter name="password">passwd</parameter> <parameter name="dbcpPooling">true</parameter> <parameter name="maxPooledConnections">10</parameter> <parameter name="isolation">SERIALIZABLE</parameter> <parameter name="compress">false</parameter> <parameter name="driver">com.mysql.jdbc.Driver</parameter> <parameter name="url">jdbc:mysql://localhost/webdavmds</parameter> <parameter name="jdbcversion">1</parameter> </nodestore> <securitystore> <reference store="nodestore"/> </securitystore> <lockstore> <reference store="nodestore"/> </lockstore> <revisiondescriptorsstore> <reference store="nodestore"/> </revisiondescriptorsstore> <revisiondescriptorstore> <reference store="nodestore"/> </revisiondescriptorstore> <contentstore classname="org.apache.slide.store.txfile.TxFileContentStore"> <parameter name="rootpath">/home/np/slide_contentstore</parameter> <parameter name="workpath">/home/np/slide_workingresource</parameter> </contentstore> </store> <scope match="/" store="memory"/> </definition> ...
On Fri, 22 Oct 2004 10:21:09 +0200, Stefan L�tzkendorf <[EMAIL PROTECTED]> wrote:
What implementation do you use for the <securitystore>? Could you supply the complete <definition> section?
Stefan
Jussi Vaihia wrote:
On creating new directories and files, as described here:
support_doc/guide_xxxx/uploaded_guide_file.txt support_doc/template_xxxx/uploaded_template_file.txt
These new directories (excluding /support_doc) and the files have the below ACL cast on them:
Subject | Action | Inheritable | Deny all | /actions/read | true | false
At this point all users have access to these new resources as intended. However, after an undetermined (random) amount of time these ACLs disappear -- causing 403 errors to users -- and I'm left to wonder why. Is there some rules to ACLs that I need to heed by, with Slide (?) otherwise removing the ACLs?
Any help on this issue is greatly appreciated!
System in use:
Slide 2.0 Tomcat 4.1.30
Snippets from domain.xml:
<slide> <namespace name="slide"> <store name="memory"> <nodestore classname="org.apache.slide.store.impl.rdbms.JDBCStore"> <parameter name="adapter">org.apache.slide.store.impl.rdbms.MySqlRDBMSAdapter</parameter> ... <contentstore classname="org.apache.slide.store.txfile.TxFileContentStore"> ... </slide>
Regards,
Jussi Vaihia
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Stefan L�tzkendorf -- [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Stefan L�tzkendorf -- [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Stefan L�tzkendorf -- [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Stefan L�tzkendorf -- [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
