[1/2] from: petr::krenzelok::trz::cz at: 24-May-2001 12:29
Hi, I would like to ask few questions. For the first time I would like to try small test with one of our customers ... We, as a sales company, want to allow them some tracking of our order-production-material dispatch prosess. It will be probably later replaced by some general e-business solution in our company, but our customer agreed to give it a try. Scenario: It is "simple" - our customer (partner) is a reseller. They want to prepare information for their customers, what is the state of process of the material they ordered. We can fill in most columns of the table for them, but last two colums is the info they get from the logistic company, once vessel arrives to port. They asked us to prepare MS Excel .xsl files for them. But I can find it a little bit contraproductive. We would have to output some info from our databases to text file, and then they would have to manually open each of the files and enter new info there. So I thought it would be better to offer them some web form, where they would fill-in the last columns, and after pressing some button e.g., some text file (in format being able to import into Excel) could be generated and sent to them via email as an attachement, or website regenerated, providing link to newly created file for them to download ... Let's say, that in some initial phase, we don't need SSL. What would we probably need is to provide some kind of authentisation. And also - what aproach to choose? Do we need (an in such case how to do it in Rebol :-) to keep connection persistent/alive (if it is the right word) to know which user is logged in, to track his activity etc.? What is general aproach in similar situations/requirements? Thanks a lot, -pekr-
[2/2] from: gjones05:mail:orion at: 24-May-2001 18:15
From: "Petr Krenzelok"
> I would like to ask few questions. For the > first time I would like to try small test with
<<quoted lines omitted: 35>>> to track his activity etc.? What is general aproach in > similar situations/requirements?
Hi, Petr, Sorry for the slow response on this thread, but I was looking for a reference that I thought would be helpful. I was unable to find it. Then the outbound leg of my email account is down so I have no idea how long it will take for this to be delivered. I've not used persistent connections with REBOL, and I can't find an example where it has been used. If the server supports it, then it can be done. The last time I dealt extensively with persistent connections (or sessions as it is frequently called in regard to the user's browser) was in 1997. I developed an ISAPI interface to IIS. What I learned is that there are a lot of things to go wrong. I ended up using a different method altogether that I will get to in a minute. If I were to deal with persistent connections again, I would probably go through one of the available packages, like PHP 4.* offers. There are still things that go bump in the night, by what I've read. Of course, temporary cookies can be used to preserve the persistance, but I'm not a cookie person. Enough people have them disabled that it requires an alternative method as a back-up, at least in my opinion. The most universal method I have found for all but the most complex of interactions can be managed using the lowest of technology: logically organized, simple html form technology and hidden fields. It is not perfect, but evidently good enough for eBay. I'll lay out a possible scenario that may be of help. I apologize in advance if this is already old information. If the customers "always" have the item identification number, then the form sequence is really simple. If the customer would need to look-up the correct identification number, then more forms are involved. (side bar: Of course, I have no idea what the actual specifications for the project are. This isjust submitted for illustration.) Form1 - Input fields for order identification number, username, userpassword. The password field uses the type=password to give the usual ****. The method action uses 'post inorder to hide parameters from the query_string. After a database query, this information brings up a form that cotains any relavent information that the customer-user would need, plus the input fields for the information to be supplied. Hidden in this form are additional input fields of type=hidden that include information about the transaction: item identification number, username, userpassword, etc. When this form is submitted, data validation can occur, and then can do on of the following 1) accept the information, if correct, 2) offer a final review of the information, asking is it correct, 3) offer a correction form to correct invalid data. The information can ultimately be submitted for updating the database, and sedning the customer the required information for their records. As far as security goes, of course the information is passed as clear, url-encoded text. The hidden data will persist in the local browser cache unless the form is set to expire correctly. The final entry can actually close out the browser so that the cache expires. The method can get out of sync if the user presses a link that interrupts the sequence (like getting help). As I said, it isn't perfect. But it is good enough for eBay, and it has been good enough for the largest proportion of what I've used, and it is platform independent, cookie independent, and session independent. These are just my thoughts. List, please no flames or holy wars regarding cookies. I would be interested if someone has managed session state in REBOL. Hope this has been of some use. --Scott Jones
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted