Billy Harvey wrote: > Bogdan, a technique I've used in the past may work for you. > > When someone wants to upload something, I have them request a cookie by > sending a blank email to a specific address. This automatically > generated cookie is good for some limited time (whatever works for you), > and will only be sent to appropriate return addresses (I use a web form > to allow the proper registration of those addresses). > > This cookie then needs to be used in the subject-line of the email - a > reply to the message would work for example. > > So, if your system gets an email with a specially formatted, and > short-lived (randomly generated) cookie in the subject, it knows what to > do with it. > > Billy
Thanks for taking the time to reply! That's the proper (and definitely secure) way to do it. However I'm looking for something not necessarily that secure, because the servers won't be public, but with a more "on-the-fly" approach for the user. You see, this feature is the alternative to uploading data by logging in the system. Logging in is no big deal - just type your username and password and you're there. Two clicks away and you can upload. This, however, would be a simple way to send an e-mail on a project you're working on to another user and simply CC the system so there's a copy there for everybody to see without spamming all the people involved. The same can be accomplished by sending the e-mail to the user, logging in and pasting the message and upload the document via HTTP. But isn't this too complicated for the average user? :-) I have two vague directions to accomplish the results I'm looking for, but I don't know if any of them is reliable/possible. The first method involves taking a better look at those headers. I noticed there are a bunch of originating information headers in the e-mail. How secure would it be to use them? Should I expect them to be there or is it that the mail servers I tested this on are nice enough to include that information? The second approach is based on the fact that the environment this system will work in is known - it's made of people who trust the company which installed the system. As such, they can easily be persuaded to perform action "X" which would result in adding a certain "secret" header to their e-mail messages. This secret header would be an all-time cookie for the respective user - the system would recognize the user by it and allow the e-mail to get posted. The second approach is rather poor even if someone can suggest some practical directions for action "X" because the whole idea behind the system is mobility and I wouldn't want users not to be able to send e-mail messages to it just because they're not using the computer in the office. I jotted it down however, so you can get an idea of where my thoughts are going... :-) Bogdan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
