From wernerm at ifusion.co.za Thu Sep 11 02:54:10 2003 From: wernerm at ifusion.co.za (Werner Moller) Date: Mon Aug 2 21:40:01 2004 Subject: [Za-pm] Maintaining state Message-ID: <2E3F96E0A649D4118AFD00105AD507BF04371486@mail.ifusion.co.za> Hi Guys, I need to maintain state (cookies, variables, sticky widgets or something) on a website where users log in and need to retrieve their information. However, the html pages and forms have already been designed with DreamweaverMX which rules out dynamic page generation with CGI. How do I go about retrieving information and placing it on the fields in the html pages after the user have logged in? I've completed the "Registration" scripts which place the information into a MySQL database. Werner Moller From mh2 at isis.co.za Thu Sep 11 03:56:30 2003 From: mh2 at isis.co.za (Mark Hewitt) Date: Mon Aug 2 21:40:02 2004 Subject: [Za-pm] Maintaining state Message-ID: <9764B5DBEDB6D4118ED20000F8004C33022AE9AF@IS240.isis.co.za> On 11 September, 2003 09:54, Werner Moller [SMTP:wernerm@ifusion.co.za] wrote: > Hi Guys, > > I need to maintain state (cookies, variables, sticky widgets or something) > on a website where users log in and need to retrieve their information. > However, the html pages and forms have already been designed with > DreamweaverMX which rules out dynamic page generation with CGI. How do I go I do believe its possible to set cookies using javascript, i.e. the client side code can check and valdiate cookies, but this is extremely unreliable and insecure, as the client can view you code, figure out how your system work, etc. > about retrieving information and placing it on the fields in the html pages > after the user have logged in? I've completed the "Registration" scripts > which place the information into a MySQL database. Well, if you want to acess data on a server side database, you have to have some kind of server side code. You basically must: 1. Show login form 2. Server side script validates information 3. If valid, server code sets cookie or starts session 4. Server side page genenrates a populate html page > However, the html pages and forms have already been designed with > DreamweaverMX which rules out Not at all, I use MX templates designed by my clients alot (well, the HTML layouts). I'd recommend PHP/Smarty combination for this, I use this alot, it allows you too keep your HTML layouts editable in dreamweaver (I beleive), as the html layout is totally independant of your code. Of course, use any tool you like, Perl with some templating system would also do, though personally I find PHP better suited to this kind of work HTH Mark --------------------------------------------------------------------------- Windows, Linux and Internet Development Consultant Cell: +27 82 9655295 Email: corporate@scriptsmiths.com Web: http://www.scriptsmiths.com --------------------------------------------------------------------------- > > Werner Moller > _______________________________________________ > Za-pm mailing list > Za-pm@mail.pm.org > http://mail.pm.org/mailman/listinfo/za-pm "DISCLAIMER: This e-mail and its attachments may contain information that is confidential and that may be subject to legal privilege and copyright. If you are not the intended recipient you may not peruse, use, disclose, distribute, copy or retain this message. If you have received this message in error, please notify the sender immediately by e-mail, facsimile or telephone and return and thereafter destroy the original message.Please note that e-mails are subject to viruses, data corruption, delay, interception and unauthorised amendment, and that the sender does not accept liability for any damages that may be incurred as a result of communication by e-mail. No employee or intermediary is authorised to conclude a binding agreement on behalf of the sender by e-mail without express written confirmation by a duly authorised representative of the sender. By transmitting this e-mail message over the Internet the sender does not intend to allow the contents hereof to become part of the public domain, and the confidential nature of the contents shall not be altered or diminished from by such transmission." From nico at itfirms.co.za Thu Sep 11 10:01:27 2003 From: nico at itfirms.co.za (Nico Coetzee) Date: Mon Aug 2 21:40:02 2004 Subject: [Za-pm] Maintaining state In-Reply-To: <2E3F96E0A649D4118AFD00105AD507BF04371486@mail.ifusion.co.za> References: <2E3F96E0A649D4118AFD00105AD507BF04371486@mail.ifusion.co.za> Message-ID: <200309111701.27486.nico@itfirms.co.za> Virtually impossible - you need some server side CGI/ServerPage intervention. On Thursday 11 September 2003 09:54, Werner Moller wrote: > Hi Guys, > > I need to maintain state (cookies, variables, sticky widgets or something) > on a website where users log in and need to retrieve their information. > However, the html pages and forms have already been designed with > DreamweaverMX which rules out dynamic page generation with CGI. How do I go > about retrieving information and placing it on the fields in the html pages > after the user have logged in? I've completed the "Registration" scripts > which place the information into a MySQL database. > > Werner Moller > _______________________________________________ > Za-pm mailing list > Za-pm@mail.pm.org > http://mail.pm.org/mailman/listinfo/za-pm -- Nico Coetzee http://www.itfirms.co.za/ http://za.pm.org/ http://forums.databasejournal.com/ To the systems programmer, users and applications serve only to provide a test load. From contrafa at biology.und.ac.za Fri Sep 12 03:18:44 2003 From: contrafa at biology.und.ac.za (Dr Giancarlo Contrafatto) Date: Mon Aug 2 21:40:02 2004 Subject: [Za-pm] Re: Za-pm Digest, Vol 3, Issue 1 RE: maintaining state In-Reply-To: <200309111700.h8BH0lM16720@mail.pm.org> References: <200309111700.h8BH0lM16720@mail.pm.org> Message-ID: <1063354494.14471.35.camel@contra> On Thu, 2003-09-11 at 19:00, za-pm-request@mail.pm.org wrote: > Send Za-pm mailing list submissions to > za-pm@mail.pm.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.pm.org/mailman/listinfo/za-pm > or, via email, send a message with subject or body 'help' to > za-pm-request@mail.pm.org > > You can reach the person managing the list at > za-pm-owner@mail.pm.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Za-pm digest..." > > ______________________________________________________________________ > > Today's Topics: > > 1. Maintaining state (Werner Moller) > 2. RE: Maintaining state (Mark Hewitt) > 3. Re: Maintaining state (Nico Coetzee) > > ______________________________________________________________________ > > From: Werner Moller > To: 'za-pm@mail.pm.org' > Subject: [Za-pm] Maintaining state > Date: 11 Sep 2003 09:54:10 +0200 > > Hi Guys, > > I need to maintain state (cookies, variables, sticky widgets or something) > on a website where users log in and need to retrieve their information. > However, the html pages and forms have already been designed with > DreamweaverMX which rules out dynamic page generation with CGI. How do I go > about retrieving information and placing it on the fields in the html pages > after the user have logged in? I've completed the "Registration" scripts > which place the information into a MySQL database. > > Werner Moller Hi folks; yes, you can do all that with client-side Java Scripting although, as Mark mentioned, there may be the odd reliability problem in cases sush as when the user bypasses your scripted page by means other than a link from a document. On the other hand, I have been doing client-side Java password validation on my site for quite a few years and have not had real problems with reliability. I suppose that's to be expected since the bulk of traffic on my site is made-up of my students, perhaps a few hundred hits a day during term: hits from outside may be as much as a dozen a day. I don't believe that security is a major problem for two reasons. Firstly, the srcipts are client-side so, besides reading priviliges, there is no access to the server: the client browser executes the script and the cookies are written to the client machine. Second, the least you'd do, would be to write your Java Script in an esternal script file, maybe served from a more secure directory, so that the users would not ordinarily get to see it, nor would they gain much information on the structure of your system. Also, if the httpd is configured securely, users would not get to view directories. A further advantage is that you would not even need to use a formated dbase file such as MySQL. All info can be stored in a flat, text file or within a reasonably hidden Java script. At the moment, for example, I keep logon info for some 100 odd students in a script without apparent loss of efficiency. It should actually be quicker that having to start an SQL server, search and validate. Admittedly, since I have control over my own server, I should do this by CGI and I may do so in the future but, for the time being, it all seems to be working fine. ciao -- all men who have achieved great things have been great dreamers. Orison Swett Marden #################################################################### Dr. Giancarlo Contrafatto School of Life and environmental Sciences University of Natal, 4041, Durban, RSA Tel: +27 031 2603336 contrafa@biology.und.ac.za #################################################################### visit Darwin at http://contra.biology.und.ac.za/ From mh2 at isis.co.za Fri Sep 12 03:40:38 2003 From: mh2 at isis.co.za (Mark Hewitt) Date: Mon Aug 2 21:40:02 2004 Subject: [Za-pm] RE: maintaining state Message-ID: <9764B5DBEDB6D4118ED20000F8004C33022AE9BF@IS240.isis.co.za> On 12 September, 2003 10:15, Dr Giancarlo Contrafatto [SMTP:contrafa@biology.und.ac.za] wrote: > On Thu, 2003-09-11 at 19:00, za-pm-request@mail.pm.org wrote: [snip] > > I need to maintain state (cookies, variables, sticky widgets or something) > > on a website where users log in and need to retrieve their information. > > However, the html pages and forms have already been designed with > > DreamweaverMX which rules out dynamic page generation with CGI. How do I go > > about retrieving information and placing it on the fields in the html pages > > after the user have logged in? I've completed the "Registration" scripts > > which place the information into a MySQL database. > > > > Werner Moller > > Hi folks; > > yes, you can do all that with client-side Java Scripting although, as > Mark mentioned, there may be the odd reliability problem in cases sush > as when the user bypasses your scripted page by means other than a link > from a document. On the other hand, I have been doing client-side Java > password validation on my site for quite a few years and have not had > real problems with reliability. I suppose that's to be expected since > the bulk of traffic on my site is made-up of my students, perhaps a few > hundred hits a day during term: hits from outside may be as much as a > dozen a day. > > I don't believe that security is a major problem for two reasons. > Firstly, the srcipts are client-side so, besides reading priviliges, > there is no access to the server This is not the problem, the problem is users can/will attempt to break your site by by passing your validation and password protection, accessing hidden pages as I think you mentioned already for example. : the client browser executes the script > and the cookies are written to the client machine. Second, the least > you'd do, would be to write your Java Script in an esternal script file, > maybe served from a more secure directory, so that the users would not > ordinarily get to see it, [snip] Not true, the browser needs to see and execute the .js file, thus it must download it to the client browser, "compile" and excute it. Therefore, the browser must have read access to the directory with javascript, and becuase it can be downloaded by a browser, it can be viewed by you. Ever tried typing url of the the src="http://www.xx.com/xx.js" tag directly into your browser? You see the source code!! > > A further advantage is that you would not even need to use a formated > dbase file such as MySQL. All info can be stored in a flat, text file or > within a reasonably hidden Java script. At the moment, for example, I > keep logon info for some 100 odd students in a script without apparent Remember, if this is as in a file, it cannot be accessed on the server by the client, and must be loaded in a javascript and send to the client, or loaded using a src="xxx.js", which is not secure (see above). This means I might be able to access login information for all your students, and login in as anybody I like. Remember, I am not saying here "never do this, its evil!!" It is maybe evil, but _everything_ you ever do or consider it dependant on _what_ you are trying to do. Sounds like your solutions is working well for you, you've been lucky and your students have not been up&coming crackers!! However, this may not be an advisable solution given a different environment, so I felt I should point out that while it works, it is not the best solution. You also need to take into account future plans and potential growth for your site, and perhaps take the extra time now to implement and solid base to enable your future extensions to deplioy more smoothly. My 2c Mark --------------------------------------------------------------------------- Windows, Linux and Internet Development Consultant Cell: +27 82 9655295 Email: corporate@scriptsmiths.com Web: http://www.scriptsmiths.com --------------------------------------------------------------------------- > loss of efficiency. It should actually be quicker that having to start > an SQL server, search and validate. Admittedly, since I have control > over my own server, I should do this by CGI and I may do so in the > future but, for the time being, it all seems to be working fine. > > ciao > > -- > all men who have achieved great things have been great dreamers. > Orison Swett Marden > #################################################################### > Dr. Giancarlo Contrafatto > School of Life and environmental Sciences > University of Natal, 4041, Durban, RSA > Tel: +27 031 2603336 contrafa@biology.und.ac.za > #################################################################### > visit Darwin at http://contra.biology.und.ac.za/ > > _______________________________________________ > Za-pm mailing list > Za-pm@mail.pm.org > http://mail.pm.org/mailman/listinfo/za-pm "DISCLAIMER: This e-mail and its attachments may contain information that is confidential and that may be subject to legal privilege and copyright. If you are not the intended recipient you may not peruse, use, disclose, distribute, copy or retain this message. If you have received this message in error, please notify the sender immediately by e-mail, facsimile or telephone and return and thereafter destroy the original message.Please note that e-mails are subject to viruses, data corruption, delay, interception and unauthorised amendment, and that the sender does not accept liability for any damages that may be incurred as a result of communication by e-mail. No employee or intermediary is authorised to conclude a binding agreement on behalf of the sender by e-mail without express written confirmation by a duly authorised representative of the sender. By transmitting this e-mail message over the Internet the sender does not intend to allow the contents hereof to become part of the public domain, and the confidential nature of the contents shall not be altered or diminished from by such transmission." From wernerm at ifusion.co.za Fri Sep 12 05:13:33 2003 From: wernerm at ifusion.co.za (Werner Moller) Date: Mon Aug 2 21:40:02 2004 Subject: [Za-pm] Maintaining state Message-ID: <2E3F96E0A649D4118AFD00105AD507BF0437148E@mail.ifusion.co.za> What do you mean with CGI/ServerPage intervention? I'm open for any suggestions. The only thing I can think of is parsing it like so: #!/usr/bin/perl use CGI qw/:standard/; # Define field variables here from MySQL data queries after login. # Open DB etc... $name = param('name'); # etc... open HTML, ") { # code here with form fields containing perl variables as values in html page. # ... print; } close HTML; # End here Do you think this will work? Still have the problem of parsing the values to the next link though. Cheers, Werner -----Original Message----- From: Nico Coetzee [mailto:nico@itfirms.co.za] Sent: 11 September 2003 17:01 To: Werner Moller; 'za-pm@mail.pm.org' Subject: Re: [Za-pm] Maintaining state Virtually impossible - you need some server side CGI/ServerPage intervention. On Thursday 11 September 2003 09:54, Werner Moller wrote: > Hi Guys, > > I need to maintain state (cookies, variables, sticky widgets or something) > on a website where users log in and need to retrieve their information. > However, the html pages and forms have already been designed with > DreamweaverMX which rules out dynamic page generation with CGI. How do I go > about retrieving information and placing it on the fields in the html pages > after the user have logged in? I've completed the "Registration" scripts > which place the information into a MySQL database. > > Werner Moller > _______________________________________________ > Za-pm mailing list > Za-pm@mail.pm.org > http://mail.pm.org/mailman/listinfo/za-pm -- Nico Coetzee http://www.itfirms.co.za/ http://za.pm.org/ http://forums.databasejournal.com/ To the systems programmer, users and applications serve only to provide a test load. From mh2 at isis.co.za Fri Sep 12 05:48:22 2003 From: mh2 at isis.co.za (Mark Hewitt) Date: Mon Aug 2 21:40:02 2004 Subject: [Za-pm] Maintaining state Message-ID: <9764B5DBEDB6D4118ED20000F8004C33022AE9C1@IS240.isis.co.za> On 12 September, 2003 12:14, Werner Moller [SMTP:wernerm@ifusion.co.za] wrote: > What do you mean with CGI/ServerPage intervention? I'm open for any > suggestions. The form submission must be handled by a CGI script on the server, be it Per/PHP/Python/etc > > The only thing I can think of is parsing it like so: > > #!/usr/bin/perl > use CGI qw/:standard/; > # Define field variables here from MySQL data queries after login. > # Open DB etc... > $name = param('name'); # etc... > > open HTML, " while () { > # code here with form fields containing perl variables as > values in html page. > # ... > print; > } > close HTML; > # End here Thats pretty much what I was alluding to in my earlier post regarding this. Except I am sure the are Perl modules already built for decent template handling, but simple find & replace of fields work 100% > > Do you think this will work? Still have the problem of parsing the values to > the next link though. In what way? You mean variables you calcuate in your example script, and want to part of the links in the template you print? In your HTML template, simply make a "variable" that will be replaced by the caculated value: [htmlpage.html]

Click here

[in cgi above] $something = calculate_it(); .... $html_output = s/\{something\}/$something/gi; .... print $html_output; > > Cheers, > Werner HTH Mark --------------------------------------------------------------------------- Windows, Linux and Internet Development Consultant Cell: +27 82 9655295 Email: corporate@scriptsmiths.com Web: http://www.scriptsmiths.com --------------------------------------------------------------------------- > > -----Original Message----- > From: Nico Coetzee [mailto:nico@itfirms.co.za] > Sent: 11 September 2003 17:01 > To: Werner Moller; 'za-pm@mail.pm.org' > Subject: Re: [Za-pm] Maintaining state > > > Virtually impossible - you need some server side CGI/ServerPage > intervention. > > On Thursday 11 September 2003 09:54, Werner Moller wrote: > > Hi Guys, > > > > I need to maintain state (cookies, variables, sticky widgets or something) > > on a website where users log in and need to retrieve their information. > > However, the html pages and forms have already been designed with > > DreamweaverMX which rules out dynamic page generation with CGI. How do I > go > > about retrieving information and placing it on the fields in the html > pages > > after the user have logged in? I've completed the "Registration" scripts > > which place the information into a MySQL database. > > > > Werner Moller > > _______________________________________________ > > Za-pm mailing list > > Za-pm@mail.pm.org > > http://mail.pm.org/mailman/listinfo/za-pm > > -- > Nico Coetzee > > http://www.itfirms.co.za/ > http://za.pm.org/ > http://forums.databasejournal.com/ > > To the systems programmer, users and applications serve only to provide a > test load. > _______________________________________________ > Za-pm mailing list > Za-pm@mail.pm.org > http://mail.pm.org/mailman/listinfo/za-pm "DISCLAIMER: This e-mail and its attachments may contain information that is confidential and that may be subject to legal privilege and copyright. If you are not the intended recipient you may not peruse, use, disclose, distribute, copy or retain this message. If you have received this message in error, please notify the sender immediately by e-mail, facsimile or telephone and return and thereafter destroy the original message.Please note that e-mails are subject to viruses, data corruption, delay, interception and unauthorised amendment, and that the sender does not accept liability for any damages that may be incurred as a result of communication by e-mail. No employee or intermediary is authorised to conclude a binding agreement on behalf of the sender by e-mail without express written confirmation by a duly authorised representative of the sender. By transmitting this e-mail message over the Internet the sender does not intend to allow the contents hereof to become part of the public domain, and the confidential nature of the contents shall not be altered or diminished from by such transmission." From contrafa at biology.und.ac.za Mon Sep 15 03:47:32 2003 From: contrafa at biology.und.ac.za (Dr Giancarlo Contrafatto) Date: Mon Aug 2 21:40:02 2004 Subject: [Za-pm] Re: maintaining state In-Reply-To: <200309121700.h8CH0gd27681@mail.pm.org> References: <200309121700.h8CH0gd27681@mail.pm.org> Message-ID: <1063615442.21804.35.camel@contra> > From: Mark Hewitt > To: 'za-pm@mail.pm.org' > Subject: [Za-pm] RE: maintaining state > Date: 12 Sep 2003 10:40:38 +0200 > > Ever tried typing url of the the src="http://www.xx.com/xx.js" tag directly > into your browser? You see the source code!! Yep, sure enough. I wasn't really arguing the point: just that you need a motivated user to go and do that. Of course, this is not all that crucial for my site since traffic is low and there is little to gain in cracking it. ABSA would think differently, no doubt. > > > > A further advantage is that you would not even need to use a formated > > dbase file such as MySQL. All info can be stored in a flat, text file or > > within a reasonably hidden Java script. At the moment, for example, I > > keep logon info for some 100 odd students in a script without apparent > > Remember, if this is as in a file, it cannot be accessed on the server by > the client, and must be loaded in a javascript and send to the client, or > loaded > using a src="xxx.js", which is not secure (see above). > > This means I might be able to access login information for all your > students, > and login in as anybody I like. > > > Remember, I am not saying here "never do this, its evil!!" > It is maybe evil, but _everything_ you ever do or consider it dependant on > _what_ > you are trying to do. > > Sounds like your solutions is working well for you, you've been lucky and > your > students have not been up&coming crackers!! However, this may not be an > advisable solution given a different environment, so I felt I should point > out > that while it works, it is not the best solution. Hehehe! You're absolutely right there. When I first deployed the script, as a test, I was expecting that the first thing the users would do, would be to go look at the script and then login exactly as you say. My log files, though, don't show many outside IPs accessing those pages at all (i.e. none in the last two months). Of course, I can't see if IPs from my institution do this but, what I've realised is that when faced with rejected logons, students tend to rather bypass the scripted page and access the document referred by it. I guess, they are just not enterprising enough and disinterested in being budding crackers. So, yah .... usually better to do it by CGI in which case, though, it would be best to construct the page on the fly rather than referring to an existing document. Thanks for the chat. ciao -- if you wish to savour your virtues, commit a sin from time to time. Ugo Ojetti #################################################################### Dr. Giancarlo Contrafatto School of Life and environmental Sciences University of Natal, 4041, Durban, RSA Tel: +27 031 2603336 contrafa@biology.und.ac.za #################################################################### visit Darwin at http://contra.biology.und.ac.za/