I know private uploads been done-to-death in the drupal forums, but I do need fresh, clear advice from other school website maintainers.
For a school website, where many of the uploaded media files will contain images and work of pupils, it is very desirable (almost necessary) to make sure they are protected so that only users with accounts can access them (meaning that urls pointing directly to files should throw a 403 error for anyone not logged into the site).
However, from the dozens of pages I've read, spanning v4.7 to v6.x, on balance it seems that placing uploads into a directory above public_html causes nothing but problems.
A)
I would love to use drupal's private upload system, so that I didn't need to worry about every single item the children/teachers upload to the site. I could give them a general warning about sharing sensitive material, and be done with it. So I would basically like to hear anyone who has got D6 and the private upload system working well with IMCE and a clutch of other media-orientated modules?
B)
The other alternative is that I drum it clearly into everyone's brains that no uploads are secure from direct linking, and place heavy restriction and moderation on everything that can be uploaded. The only merit in this is that it may teach the children to be wary of what they publish on other websites like myspace, flickr, facebook, etc.
However, it will be very detrimental to the amount of material we can upload to the site. It is one thing to share personal work or semi-sensitive documents within our school community, and quite another to have some idiot share the direct link to it on the rest of the net. Is anyone in a similar situation? Thoughts? Ideas?
C)
I'd also like to know what will happen in D7 or further in the future?
· Will there there an improvement in the private upload system?
· If so, do I need to choose 'private' now in D6 to use the improved private upload after upgrading to D7?
· Will all the modules which currently get broken by private uploads ever eventually be fixed?
It seems to me that many users, especially in education, are crying out for file protection, not just in drupal but on the net generally. Is this something I can say to the headmaster 'not now, but in a couple of years we'll be able to protect files'?
Thanks.
BTW, this is my first usage of 'groups'. Is this a default version of the OG module?
Comments
Hmm... 50 new posts since I
Hmm... 50 new posts since I posted this yesterday, and no thoughts yet about 'the world' being able to directly link to student's images/work or internal school documents, all intended for website members only.
Is that because:
· no-one cares too much because it isn't much of a problem?
· there is no good privacy solution for direct-linking so there's no point in thinking about it?
· school websites use the 'private upload' system and a files directory above root, all working perfectly?
Apologies if I sound impatient.
I'm trying to reach a deadline for Sept/Oct, and need to decide whether to use private or public.
As you know, once the choice has been made, you can't easily go back when you find a module borks.
Thank you for any opinions or information.
We've done both
If privacy is the main concern, then you should probably consider a walled garden, in conjunction with private upload.
We have rolled out private uploads with no issue.
As for switching after the fact, it's a nuisance, but really, it just requires updating the path to files in the db, in the files table, IIRC. Not best practice in any way, shape, or form, but manageable if you take your time, have backups, etc.
FunnyMonkey
Tools for Teachers
FunnyMonkey
LDAP / Cosign?
Do you have any kind of https / cosign / single sign on authentication system in place?
For example, anything within the folder elearning_courses on our server you have to be logged in as a member of Penn State in order to see thanks to Webaccess / Co-sign. This way we don't have to bother with the private file uploads issue bc we know that they have to be from PSU if they are able to get to material within that folder. If you're doing anything with LDAP (or have the ability to) you could also write up a simple .htaccess group requirement of users to be part of the school's LDAP group (or a specific one) in order to gain access to the files within that folder. Granted now, EVERYTHING within that folder will be private to the school / school district but then you can be safe from predators since I know there's a lot of concern in K-12 for that sorta thing and kids pictures / anything identifiable.
Outside of having a security system in place like this you'd have to write up something proprietary that routes all files traffic through a .php or some private-ish drupal thing.
"Plaguing the world with Drupal; One Plone, Moodle, Wordpress, Joomla user at a time since 2005." ~ btopro
http://elearning.psu.edu/
http://elearning.psu.edu/projects/
http://elearning.psu.edu/drupalineducation/
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
Thanks for your replies.>
Thanks for your replies.
I get the feeling that you are talking about some kind of school district network,
managed by full time experts, with all sorts of bells and whistles attached.
We are a small private school with no affiliation to any governmental provision
like that. I'm not even the IT guy, just a teacher. But I am going to be at the school
for the next few years, whereas our IT techs never last more than a year or two. Since
the website needs continuity, I got the task of creating developing and maintaining it.
Our website is on a normal webhost, not on the school intranet, because there is
no-one good enough here to be able to run apache/php/mysql safely from hacking,
and opening up our intranet to all sorts of security risks. So use of a webhost is a
sort of sandbox, if you like, to protect our network (where the really confidential
stuff is) from the outside world.
I was rather hoping that drupal would provide the security we need for the website!
I don't quite understand 'with no issue', because everything I've read so far states
that the private option breaks many modules, especially file and media handling
ones, and that it has a large performance hit.
I would love to hear someone with experience say that these problems don't exist!
Hello, RE: I get the feeling
Hello,
RE: I get the feeling that you are talking about some kind of school district network,
managed by full time experts, with all sorts of bells and whistles attached.
No. We have done both large rollouts, and helped on smaller rollouts where they have a very part-time tech person responsible for maintaining the site.
RE: Our website is on a normal webhost, not on the school intranet, because there is
no-one good enough here to be able to run apache/php/mysql safely from hacking,
This is not abnormal, and what I inferred from your post.
RE: I don't quite understand 'with no issue', because everything I've read so far states
that the private option breaks many modules, especially file and media handling
ones, and it has a large performance hit.
When I said, "no issues" I meant just that: no issues. Everything works. We have rolled out sites using private file handling with the audio module, embedded media field, and with imagefield.
RE: I would love to hear someone with experience say that this isn't the case!
You just did. Twice. Private uploads worked with the audio module, and imagefield. At the risk of stating the obvious, it also worked with Embedded Media video, because the video was coming from outside the site.
If you have specific questions about other modules, please ask them, but also, look through the issue queues for these modules, and look at the release notes. For example, the Imagefield 5.x-2.0 and Imagecache5.x-2.0 release notes indicate that private uploads are supported.
Are there other specific file handling modules you have questions about?
RE: Apologies if I sound impatient.
You do sound impatient. People are here freely sharing their experience. The more specific you can be with your questions, the more precise we can be with feedback.
RE: I'd also like to know what will happen in D7 or further in the future?
We all would. At this point, I'm betting on FileField, or something similar. See http://groups.drupal.org/node/11810 and http://drupal.org/node/142995 for some additional context.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
> This is not abnormal, and
I don't know what type of webhosting accounts schools usually have, but I can't run things
like cosign, ldap, openID server on ours - it's a basic shared business hosting account.
No shell access.
Thanks for your confident clarification. Sorry if I sounded distrustful, but there are hundreds
of threads about the private upload system bringing nothing but pain and anguish.
Actually I have been experimenting with the private file system today, and hit a problem.
If nodes are enabled for anonymous users, they can't see any images in the pages.
That's no good at all because I wanted everything to be private by default, but then certain
projects (scattered nodes collated into 'books') made public after the content being checked
and deemed suitable and no-risk. This would be impossible without moving all the inserted
images and media into a different folder and then editing all the internal links in the nodes.
... unless I let parents sign up to the website too, but I'm not equipped to manage that.
It'll be bad enough managing the pupils' accounts.
I think on reflection, the private file system is not viable as an 'all or nothing' approach.
Thanks for your advice so far.
Clarifying the public/private sections
The first thing I'd recommend doing, before worrying about public and private file handling, is sort out who can see what based on roles. Then, you can make a choice on node-based access control. On the basis of what you have described, organic groups or workflow access could be a good fit for your node based access control.
Basically, if a user can see the node, you will want them to see the files -- and this makes hiding uploaded files from anon users problematic if anon users can see selected pieces of content.
Feel free to ping back with additional questions.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
Thanks for the heads-up
Thanks for the heads-up about 'workflow'. I'd not seen that. The headmaster (a bit of a control-freak) would probably love to moderate all submissions! lol.
I'm using the 'node privacy by role' module. This really suits our needs very well.
The only thing I was trying to prevent is direct linking to the files inserted into content. I erroneously thought that drupal could somehow apply the permissions of a node to all the files inserted into it. But researching it and thinking about how the internet works, I now see that it would be almost impossible.
However, I've been thinking about the issue more and have decided this:
For private nodes, guests would have to guess the filenames. The only way they can link to a file directly is if a student with access shares the url. I could stop students doing that using the private file system, BUT the student could still simply save the file and upload somewhere else. In other words, I can't stop students sharing any file that they have access to, I can only make it marginally harder. I think node-access control will have to suffice, in partnership with teaching responsible uploading.
> Feel free to ping back with additional questions.
I do have another problem, regarding registration, if you don't mind discussing it here. I've tried the forums, but it isn't a very large issue with 99% of websites, so I couldn't get much response. The problem is that drupal won't let pupils register without supplying an email address. There are two issues:
1) many children don't have an email address (and are too young IMO), and some won't want to share theirs, even if it is only stored for admin purposes.
2) if the solution allowed some students to have a registration email, and others to have a dummy email (or even leave the field blank), then I'm afraid that other features, which may assume an email address is present, might crash or cause errors.
3) if email isn't used, drupal 6 doesn't have any messaging facility. I would like some sort of internal messaging system because it doesn't carry any of the risks which normal email entails, and would encourage students to log in more often (to check their messages).
I tried the localemail module, but it doesn't install (plus the project looks dead).
So, a drupal 6 community without email! Is it possible? What does everyone else do?
Cheers.
messaging in Drupal 6
This is probably something you can do with a combination of CCK and Views. You create a new content type, let's call it 'Message'. To the message type, you create a User Reference field.
You then create a view of all of the messages where the user reference field matches the current user. Then there are some solutions to add an 'unread' filter to the view.
With some fiddling and theming of the view, you could end up with something that mimicks an email box. Best part is, no email address required.
Dave
The coherent_access module
Actually, the coherent_access module would do it, and allow for private messages between users. If all users have emails, it also emails people when they have been messaged, but the default module creates a tab on the user's profile page that shows all nodes they have rights to see.
We're currently working on the D6 port; it will be up shortly -- probably/hopefully within 2-3 weeks.
http://drupal.org/project/coherent_access
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
> We're currently working on
Awesome. I'll keep an eye on it and help test if I can.
However, that still leaves the main problem of user-registration without the need to supply an
email address - and this is my main concern.
The only thing I can think of is, after receiving an email request for an account, for me as admin
to create the account using a dummy email address like: user@sub.domain.net and set-up a
cpanel-11 filter to simply blackhole all mail to/from that subdomain.
That's very messy though. Any better suggestions?
Again, how do you guys get around middle-school students who don't have or don't want to use
their email addresses to sign up for the school website?
Should we be asking for an 'registration email is optional' feature in drupal core?
Thanks.