What I'm currently thinking is: if you are setting the permission via ACL the properties are held in the cache and therefore they work. If you restart the webapp or after some time they are deleted from cache they disapear. That may have two reasons: they are not properly stored in the database and thats why after rereading permissions they are lost or they are stored, but not reread correctly. It is a first guess only.
Yes, the table is not quite readable (:-), I need a closer look too.
I now have a meeting, but I will keep in with this ASAP. Stefan
Jussi Vaihia wrote:
I'm afraid I'm not (yet) experienced enough to properly understand the table data in PERMISSIONS to properly answer your question. What should I be looking for?
Basically you are saying the problem is that the program code sets ACL permissions, which Slide picks up (and shows properly), but does not store them (Subject "all") in the database -- so they're lost on any tomcat/slide hiccups?
-Jussi ( I'm debugging code made by others so please bear my inexperience on this subject. )
On Fri, 22 Oct 2004 14:00:16 +0200, Stefan L�tzkendorf <[EMAIL PROTECTED]> wrote:
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]
--------------------------------------------------------------------- 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]
