[Building Sakai] Setting a resource's permissions

Diego del Blanco Orobitg diego.delblanco at samoo.es
Wed Sep 5 09:04:25 PDT 2012


I agree totally with Matthew about the way of do this.

 

About the  problem of students don’t seeing eachothers certificates I launch
some ideas only as a brainstorming, maybe can be useful for you as the
origin of the final idea:

1.        Simplier, but surely not the best solution
 maybe dropbox tool can
be a simple solution and your code can put the certificate in each student
dropbox folder, or maybe 

2.       If you are not sure about having dropbox in your sites, you can put
it in a folder in the workspace’s Resources tool of each student. 

Something as:

               -Certificates

                               -ANU1002

                                              Certificate.pdf

                               -ABS0299

                                              Certificate.pdf

3.       Well I don’t have in mind the design of your tool, but other option
is to put the tool available to the students and when the press the button
of “generate certificate” they download a pdf dynamically generated directly
from the tool and not stored in any other place before. Maybe this tool can
be in myworkspace and allow the student download certificates for all their
courses (when available, of course)

4.       Send it by mail to the student (it can be lost
)

 

 

Certificates tool can be a very useful tool and surely there are a lot of
universities interested in this.

 

Saludos

 

diego

 

 

De: Matthew Jones [mailto:matthew at longsight.com] 
Enviado el: miércoles, 05 de septiembre de 2012 17:18
Para: Brian Baillargeon
CC: Diego del Blanco Orobitg; sakai-dev at collab.sakaiproject.org
Asunto: Re: [Building Sakai] Setting a resource's permissions

 

I believe what the code would have to do is switch the user to a user the
does have access, push through a security advisor, access the content, then
pop it off. This requires more work and opens up the possibility of a
security issue but it's what other tools do to get around similar issues.
It's either this or obscurity I guess. There's no way for the *system* to
have access that the user context doesn't. 

 

As far as your other point, all it does is generates PDF's with the forms
filled out. I can't see any way the student couldn't just save the PDF to
their desktop and share the certificate if they did feel like doing that. Or
even taking a screen shot if somehow the certificates weren't savable and
recreating the certificate. Anything that can be seen can be reproduced, and
digital objects more easily than others. You'd have to apply some type of
digital certificate but that would only apply to the actual digital
document. 

 

That's why something like the Mozilla badges will probably have more "value"
than a certificate like this because it's something that can be verified
against multiple sources of achievement similar to how a degree can be
verified by contacting the university. The paper alone isn't proof of
anything. ;)

 

On Wed, Sep 5, 2012 at 10:47 AM, Brian Baillargeon <bbailla2 at uwo.ca> wrote:

So, just to clarify - is there a way for students to be denied access to the
pdf templates, while maintaining the ability to trigger the certification
tool to read the pdf for them? Also, something that's been at the back of my
mind is preventing students from seeing eachother's awarded certificates. We
may not need this latter functionality, but I suspect we will.



On 12-09-05 10:31 AM, Matthew Jones wrote:

Well the problem is for the certificate tool, the students need permission
to access the certificate templates because they need these templates to
generate their actual certificate. The tool or services needs to be able to
access the file in the context of the student to generate the filled in
template. The tool could potentially override this with a local
SecurityAdvisor but then you're getting into a lot more code and a potential
security problem. 

 

The students won't ever see this internal URL though and won't be able to
browse the actual file names, so the chances of them guessing it should be
about the same as a brute force password attack.

On Wed, Sep 5, 2012 at 10:30 AM, Diego del Blanco Orobitg
<diego.delblanco at samoo.es> wrote:

Hidden is the word, but really they don't have permissions to access in any
way neither knowing the url, because they need the "View hidden resources"
permission that is checked when accessing to a resource that is hidden.

So finally all depends on the permissions security system. It's almost the
same than change their read or write permission for that folder.

Diego


-----Mensaje original-----
De: Brian Baillargeon [mailto:bbailla2 at uwo.ca]
Enviado el: miércoles, 05 de septiembre de 2012 16:16
Para: Diego del Blanco Orobitg
CC: sakai-dev at collab.sakaiproject.org
Asunto: Re: [Building Sakai] Setting a resource's permissions


Yes, it seems this is the way to go. I'm a little concerned about security
by obscurity, but I'll discuss it with my team

On 12-09-05 07:24 AM, Diego del Blanco Orobitg wrote:
> There is the hide option for any folder or file in resources.
>
> Maybe instead try  to change permissions, you can use "public void
> setAvailability(boolean hidden, Time releaseDate, Time retractDate)"
> from the ContentHostingService to edit a collection and hide a folder
> to the users without the permission of "view hidden resources".
> Students usually have this permission disabled by default and instructors
have it enabled.
>
> Saludos!
>
>
> Diego del Blanco Orobitg
> Director de operaciones
> diego.delblanco at samoo.es
> Tlf Oficina: 673 80 32 69
> Tlf Móvil: 653 683 489
> www.samoo.es
>
> -----Mensaje original-----
> De: sakai-dev-bounces at collab.sakaiproject.org
> [mailto:sakai-dev-bounces at collab.sakaiproject.org] En nombre de Brian
> Baillargeon Enviado el: martes, 04 de septiembre de 2012 20:33
> Para: sakai-dev at collab.sakaiproject.org
> Asunto: [Building Sakai] Setting a resource's permissions
>
> Hi all,
>
> I'm working on a fork of the certification tool. I want the tool to
> save PDFs somewhere in the site's resources rather than
root/certification/...
> However, I don't want students to have any permissions to view/modify
> the template PDFs, so I want to disable all of the resource
> permissions (such as Create resources, Read resources...) on the
> related directories for roles who don't have certificate.admin
permissions.
>
> So for example, if we had
> root/certification/templates/<siteId>/<certificateDefinitionId>/myPdf.

> pdf In my implementation it should be somewhere like
> <siteCollection>/certification/templates/<certificateDefinitionId>/myP
> df.pdf and the <siteCollection>/certification/templates/ folder's

> permissions would all be enabled for Instructor and disabled for
> Student
>
> I've been poking around ContentHostingService, and I see ways to check
> for permissions but nothing to set them. I also poked around in
> AuthzGroupService, but didn't see how to use it with ContentResources.
> Does anybody know a way to set permissions on a ContentCollection?
>
> Thanks,
> Brian
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
>

_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
with a subject of "unsubscribe"

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20120905/232b35fa/attachment.html 


More information about the sakai-dev mailing list