RE: [PHP] Logging on to a web based application

Yuck!! I personally turned off flash in all of my browsers and cut it out of the systems in the office. It's a resource hog, it's a pain in the buttocks on a page, and now sites are using it for ads. So on top of having most registered ad servers blocked via hosts file I run pop-up killers on everyone's PC with a new copy of my own database to keep it up to date. Yuck on using flash!!! I think I sent a better way, but that is my opinion. I can't see where it is going to go wrong with using the PHP session to associate it with the current user/PC. Sure, 12 users might be trying to use the application, but by the same token, it gives the user access to the application multiple times in a day. I track users on our intranet using just webalizer and the httpd access log. I go in and out and have it NOT show my logins with the rest of the users, since I am in the site about 12 times in a day. So far I have not had a single issue with folks and the session script. Robert -----Original Message----- From: Miles Thompson [mailto:milesthompson@ns.sympatico.ca] Sent: Friday, January 30, 2004 9:46 PM To: Shaun; php-general@lists.php.net Subject: Re: [PHP] Logging on to a web based application At 06:38 PM 1/30/2004 +0000, Shaun wrote: >Hi, > >We are trying to develop a web based system where users a charged per >office. I would be grateful to hear anyone's experience in creating >such applications and how the users are managed. Our main concern is >how we stop a client paying for one office use and distributing their >password to other offices... > >Many thanks Send Bruno 'round to break their knees! The PC is not an inherently secure device, so anything is a kludge. At present, for a paid newsletter, accessible only via the Internet, we do two things: 1. Limit logins - they get 10/wk. 2. Use Flash to run the login / display the news, with PHP backend authenticating and fetching/returning the news stories as an XML feed to the .swf. This is all integrated in Flash to solve the problem of users forwarding the newsletter to their "friends". If someone goes to the browser cache and forwards the .swf, so what - the first thing the recipient sees when running it is a login screen. If the username/password gets passed around, the allowed logins get used up v. quickly, so the damage is limited. The check_key generated by the authentication script is stored by Flash in a .sol file, so after initial authentication the login is automatic. Subscribers like that, and of course there is the minority who don't realize that each time they open the news link they are using up a login. <g> Printing is handled somewhat obtusely. First of all a subscriber has to have permission to print, and popups from our site enabled. Flash calls a JavaScript function which pops open a new browser window, which uses the already established authentication to create a session and call the printing script. This window immediately then itself as its own parent and closes. The child called by this window is chromeless, has all text selection features etc. turned off, uses JavaScript to call the print dialog on load, and offers only a "Close" button to the user. That is if there is a valid session, otherwise it displays normally and suggests there may be a problem with the subscription and the user should contact the office. We have to go through these weird hoops for printing because printing from Flash is a horrible experience, unless it's been improved in MX 2004. Judging by the threads on Flashcoders I'd say it hasn't. Because this is a newsletter, and varies in length from day to day the flexibility of browser output works better; we'd go nuts trying to fill and combine the right number of pages in Flash. Before that, we had a convoluted system that everyone hated - it really tied the user down, and one staff person had to spend about 32~3 hr per day resetting subscribers settings. Here's how it worked. User logged in, a check_key was generated and sent to user's browser (cookie). The check_key value and a logged_in flag set to true were stored in the database along with the users other information. The slick part was that once the user had gone through the process, on one browser on one computer, when they went to the site again they did not have to log in - they were automatically validated and the .pdf (newsletter) was automatically downloaded. The down side was that it would only work with one browser on one machine. If a subscriber tried to log in from another machine the combination of logged_in = true, and a check_key resulted in a warning message to the effect that either the data could not be found or that there was successful use of the site registered to another computer/browser combination. The worst offenders for passing around the newsletter were lawyers. Over the past year we've also turned off the print function for most of them. We also looked at Adobe's PDF Merchant (or whatever it's called now) but it was too expensive, levied a royalty on each use, and within 3 months of its announcement a Russian CS student had cracked Adobe's protection scheme for .pdf's. Other than that it was cool. So I will close with a further recommendation for Bruno, and a reminder that a PC is an insecure device. Regards - Miles -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php