Thanks for the reply Dieter,
Tim Hicks writes:
I'm having difficulties 'artificially' logging in a user from filesystem python code. Your "acl_users" has a "validate" or "authenticate" method. Call it, to log in your user.
I'm calling "authenticate" already. Here's the code I'm using again; <begin> #Get hold of the original upload folder folder = context.restrictedTraverse(qfile.upload_url) #Authenticate with the same acl_users as the original uploader acl_users = folder.acl_users user = acl_users.authenticate(qfile.user, qfile.passw, request={}) user = user.__of__(acl_users) newSecurityManager(None, user) <end> I just looked at the "validate" method of the BasicUserFolder class in AccessControl.User, and I don't really understand how I would use it in my case. It's arguments are 'request, auth, roles', whereas I have a username and password that I'd like to use to authenticate with. What am I missing? Just to be clear, the authentication appears to work, but only for the first level of protected code, second level protected code (i.e. that called from first level) seems to fail, although I can call manage_addFolder()... wierd. As an aside: I added in the """user = user.__of__(acl_users)""" because I was getting AttributeErrors (I think) on 'aq_inner' from my user object. I presumed I needed to wrap the user object to get it to work properly.
I'm trying to setup a queuing system for converting files that users upload. The uploads are pickled to the filesystem and I then use Xron to fire the conversions at regular intervals. Once the conversion is done, I want it added to the ZODB (along with various default methods), but I also need to check whether the user has permission to add files to the place they tried. I'm trying to perform this check when the scheduled conversion takes place as opposed to when the upload takes place, so I capture the username/password of the uploading user and store it in the pickle. Why do you not do it immediately? It would give the user much better feedback.
I started off not doing it automatically because the queue mechanism was separate from the upload. I agree, raising an error on the upload would be good feedback. But given that the queue time is potentially quite long, I figure the user permissions and/or the action on the queued file may be changed in that time (it is web-configurable). To me, the system seems to have better integrity if checks are done at the time of commitment to the ZODB. As for user feedback, they are informed via email of developments. cheers tim