Forum OpenACS Development: File Storage permissions checking

Collapse
1: File Storage permissions checking
Posted by Eduardo Santos on 10/25/07 10:03 PM
I was trying to create a public folder inside the community file-storage, when I realized that it can't be donne. Even if I change the folder permissions to grant The Public read access, if I try to view the folder the system moves me to the login page.

I don't know if it's a bug or if it should behave like this, but it doesn't seem the right behavior to me. If I want a folder to be public, it should be, no matter where it is.

So, how can I change this? Does it have something to do with the request processor?

Obs.: I'm using OpenACS 5.2.3 and dotLRN 2.2.0

Collapse
2: Re: File Storage permissions checking (response to 1)
Posted by Dave Bauer on 10/25/07 10:11 PM
The public can see the folder of course, they just can't access the URL of the folder which is within the community.

Its the correct behavior since the entire community is private.

There is no simple way to change that. .LRN is designed to keep everything within a community private to the community members.

Collapse
3: Re: File Storage permissions checking (response to 1)
Posted by Malte Sussdorff on 10/26/07 08:50 AM
As the file storage package is a package, you could mount it outside the community again (open URL), give the community permissions on the package and the public read on the folder. So much for the theory 😊.
Collapse
4: Re: File Storage permissions checking (response to 3)
Posted by Eduardo Santos on 10/26/07 01:06 PM
Hi Malte,

Thanks for the help. So, how is this url permission done? Does it have anything to do with the request processor implementation for dotLRN? As the problem is getting much bigger than I tought, maybe I'll follow your suggestion and mount a file-storage folder wich will be public for everybody.

Collapse
5: Re: File Storage permissions checking (response to 4)
Posted by Don Baccus on 10/29/07 11:10 PM
Well, the request processor does check to see that the user has the 'read' privilege on the package.

This is correct and you shouldn't even think about changing this.