From jptillman at comcast.net Wed May 7 20:59:19 2003 From: jptillman at comcast.net (James Tillman) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] [Fwd: Newsletter from O'Reilly UG Program, May 6] Message-ID: <1052359159.3257.0.camel@jacob.home> Latest from O'Reilly is attached. jpt -------------- next part -------------- An embedded message was scrubbed... From: Marsee Henon Subject: Newsletter from O'Reilly UG Program, May 6 Date: Tue, 06 May 2003 18:52:29 -0700 (PDT) Size: 17650 Url: http://mail.pm.org/pipermail/tallahassee-pm/attachments/20030507/208edba8/attachment.eml From phillip.tyre at fcul.com Fri May 9 10:58:31 2003 From: phillip.tyre at fcul.com (Phillip Tyre) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] Hello everyone. Message-ID: <39B5739894E97B40A427C59317BF2CD3878D37@exchange2k.fcul.com> I've lurked here for a bit, and figured I should finally say hello to the list. I'm really not much of a Perl programmer to be honest. I've skimmed a few tutorials, and the camel book, but most of the perl experience I have has come from working with other people's code. You can't really dabble in open source much without encountering a lot of perl, and most of my work has been in the area of understanding, working with, and configuring options for other peoples code. I'd say my area of greatest interest at the moment is in PHP more than perl, but since PHP is a fairly clear derivative of perl, I'd hope everyone doesn't mind if I hang out and ask silly questions on occasion. Phillip Tyre -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/tallahassee-pm/attachments/20030509/cbaedd38/attachment.htm From ToddCushard at fdle.state.fl.us Fri May 9 10:52:00 2003 From: ToddCushard at fdle.state.fl.us (Cushard, Todd) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] Hello everyone. Message-ID: <2265699E79C5D51197940002B31B4EDB4C53CD@exchange.fdle.gov> Only unasked questions are silly. You're more than welcome. Todd Cushard -----Original Message----- From: Phillip Tyre [mailto:phillip.tyre@fcul.com] Sent: Friday, May 09, 2003 11:59 AM To: tallahassee-pm@mail.pm.org Subject: [Tallahassee-pm] Hello everyone. I've lurked here for a bit, and figured I should finally say hello to the list. I'm really not much of a Perl programmer to be honest. I've skimmed a few tutorials, and the camel book, but most of the perl experience I have has come from working with other people's code. You can't really dabble in open source much without encountering a lot of perl, and most of my work has been in the area of understanding, working with, and configuring options for other peoples code. I'd say my area of greatest interest at the moment is in PHP more than perl, but since PHP is a fairly clear derivative of perl, I'd hope everyone doesn't mind if I hang out and ask silly questions on occasion. Phillip Tyre -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/tallahassee-pm/attachments/20030509/f6f42a79/attachment.htm From phillip.tyre at fcul.com Fri May 16 13:15:31 2003 From: phillip.tyre at fcul.com (Phillip Tyre) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] PHP authentication Message-ID: <39B5739894E97B40A427C59317BF2CD31B05B6@exchange2k.fcul.com> Has anyone had any experience with a custom perl, or PHP based authentication framework using mysql as the back end? I've done some looking, but all the ones I've seen tend to make the same basic assumptions. Once you authenticate the user, and set a cookie, then you can trust all the cookies that are set for that user (admin status, username, etc). I'm really looking for something more secure, where the actual session table in the database would hold the permissions, and based on a matching session, the table would be queried to retrieve the permissions. Am I way off base on this? Phillip Tyre P.S. This message brought to you because of the heavy silence this list has experienced since the last time I posted. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/tallahassee-pm/attachments/20030516/99231e7b/attachment.htm From JamesTillman at fdle.state.fl.us Fri May 16 13:31:00 2003 From: JamesTillman at fdle.state.fl.us (Tillman, James) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] PHP authentication Message-ID: <2265699E79C5D51197940002B31B4EDB06C0094F@exchange.fdle.gov> Yes, the silence has been unfortunate. I've been up to my ears in work these last few weeks. In my own previous work, I have been able to go a little further than simply setting a cookie in the browser and trusting it from then on. What I've done in the past with my own security systems was: * Create a large randomized string (20 chars min.) and use that value as a session key (I call it a "ticket"),which gets stored in the database as being tied to a particular user, and is then sent to the browser as a cookie along with another cookie indicating the username. * Each "ticket" has an expiration time of about 15 minutes (not an actual HTTP cookie expiration time, but a time my code keeps track of). This time can be as long or short as you want, depending on how paranoid you are. * Each time the browser accesses the web app, my server side code verifies that the cookie value matches the current ticket that is stored in the database for that user (or that is cached on the web server somehow -- it doesn't have to be a database, see Apache::Session), and that the "ticket" hasn't expired. * If the ticket has expired, a new one is generated, stored in the db, and issued to the browser without the user being any the wiser. * If an invalid ticket is passed in, all valid sessions for that user are deleted, and the user is asked to log in again. The end result is that it becomes very difficult for someone to hijack a user's session because they must be able to send in the usercode cookie and the ticket cookie, which is very hard to guess. Even if they manage to do that, they'll only get 15 minutes (or whatever I've set the expiry to be) before they blow up the session and force a login, since either their browser or the legitimate user's browser will send an invalid ticket once a new one gets issued and the system will kick them both out. This has worked very well for me in the past, and when coupled with a method for IP address matching, it becomes even more secure. Essentially, if you need more security than this, I'd say it's time to add SSL into the mix. hope this helps! jpt -----Original Message----- From: Phillip Tyre [mailto:phillip.tyre@fcul.com] Sent: Friday, May 16, 2003 2:16 PM To: tallahassee-pm@mail.pm.org Subject: [Tallahassee-pm] PHP authentication Has anyone had any experience with a custom perl, or PHP based authentication framework using mysql as the back end? I've done some looking, but all the ones I've seen tend to make the same basic assumptions. Once you authenticate the user, and set a cookie, then you can trust all the cookies that are set for that user (admin status, username, etc). I'm really looking for something more secure, where the actual session table in the database would hold the permissions, and based on a matching session, the table would be queried to retrieve the permissions. Am I way off base on this? Phillip Tyre P.S. This message brought to you because of the heavy silence this list has experienced since the last time I posted. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/tallahassee-pm/attachments/20030516/d509ae47/attachment.htm From JamesTillman at fdle.state.fl.us Fri May 16 13:34:05 2003 From: JamesTillman at fdle.state.fl.us (Tillman, James) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] PHP authentication Message-ID: <2265699E79C5D51197940002B31B4EDB06C00950@exchange.fdle.gov> Oh, and I failed to see your other question about permissions. I've also done some work in that area, too. I've always stored the perms that were pulled from the database in a session-type cache -- again, see Apache::Session (works with CGI, too) -- or simply retrieved it from the database each time, depending on the performance requirements. jpt -----Original Message----- From: Phillip Tyre [mailto:phillip.tyre@fcul.com] Sent: Friday, May 16, 2003 2:16 PM To: tallahassee-pm@mail.pm.org Subject: [Tallahassee-pm] PHP authentication Has anyone had any experience with a custom perl, or PHP based authentication framework using mysql as the back end? I've done some looking, but all the ones I've seen tend to make the same basic assumptions. Once you authenticate the user, and set a cookie, then you can trust all the cookies that are set for that user (admin status, username, etc). I'm really looking for something more secure, where the actual session table in the database would hold the permissions, and based on a matching session, the table would be queried to retrieve the permissions. Am I way off base on this? Phillip Tyre P.S. This message brought to you because of the heavy silence this list has experienced since the last time I posted. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/tallahassee-pm/attachments/20030516/bb869fc9/attachment.htm From phillip.tyre at fcul.com Fri May 16 13:42:53 2003 From: phillip.tyre at fcul.com (Phillip Tyre) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] PHP authentication Message-ID: <39B5739894E97B40A427C59317BF2CD31B05B7@exchange2k.fcul.com> That helps a ton. That is actually a lot like the system I was picturing, except you've obviously done a bit more thought on the expiration side of the problem. I'm very leery about coupling the system with client IP matching, just because of the poor sods on AOL and MSN, and all the fun proxy things both services do. SSL is a definite, but the problem that I worry about, but few others seem to, is the problem of a valid user executing a privilege escalation. And that is what most systems I see seem to leave wide open. Everyone who codes a website service seems to end up writing their own session system. Let me take that back, I've seen session systems that are supposed to be able to plug into anything you want to create, but again, they just don't seem that secure. There should be a nice, paranoid custom database driven session framework in open source, and then we could have a great time tying all the nice web services out there into the same backend without going insane. Speaking of paranoid, how's this? function sessionid() { // The purpose of this function is to generate a 110 digit, // case sensitive alphanumeric session ID for the purpose of // tracking active logins. It uses multiple entropy sources. // Generating large random numbers can be resource intensive, // So the upper limit of the random numbers can be tuned to // provide the right balance of uniqueness, and system performance. # Generate a unique ID based on the server clock $uid_clock=uniqid(1); # Generate a random number called $rand_num1 $rand_num1=rand(1, 1000000000000); # Generate a random number called $rand_num2 $rand_num2=rand(1, 1000000000000); # Calculate a md5 hash of each random number separately $rand_hash1= md5($rand_num1); $rand_hash2= md5($rand_num2); # Generate user_remote_info based on the client ip and port, if they exist. $user_remote_info = $_SERVER['REMOTE_ADDR'].$_SERVER['REMOTE_PORT']; # Calculate a hash based on the remote user info $user_remote_hash= md5($user_remote_info); # Combine the above hashes, and unique id's to create a relatively # unique and hard to guess string $nsessionid= $rand_hash1.$uid_clock.$rand_hash2.$user_remote_hash; return $nsessionid; } -----Original Message----- From: Tillman, James [mailto:JamesTillman@fdle.state.fl.us] Sent: Friday, May 16, 2003 1:31 PM To: Phillip Tyre; tallahassee-pm@mail.pm.org Subject: RE: [Tallahassee-pm] PHP authentication Yes, the silence has been unfortunate. I've been up to my ears in work these last few weeks. In my own previous work, I have been able to go a little further than simply setting a cookie in the browser and trusting it from then on. What I've done in the past with my own security systems was: * Create a large randomized string (20 chars min.) and use that value as a session key (I call it a "ticket"),which gets stored in the database as being tied to a particular user, and is then sent to the browser as a cookie along with another cookie indicating the username. * Each "ticket" has an expiration time of about 15 minutes (not an actual HTTP cookie expiration time, but a time my code keeps track of). This time can be as long or short as you want, depending on how paranoid you are. * Each time the browser accesses the web app, my server side code verifies that the cookie value matches the current ticket that is stored in the database for that user (or that is cached on the web server somehow -- it doesn't have to be a database, see Apache::Session), and that the "ticket" hasn't expired. * If the ticket has expired, a new one is generated, stored in the db, and issued to the browser without the user being any the wiser. * If an invalid ticket is passed in, all valid sessions for that user are deleted, and the user is asked to log in again. The end result is that it becomes very difficult for someone to hijack a user's session because they must be able to send in the usercode cookie and the ticket cookie, which is very hard to guess. Even if they manage to do that, they'll only get 15 minutes (or whatever I've set the expiry to be) before they blow up the session and force a login, since either their browser or the legitimate user's browser will send an invalid ticket once a new one gets issued and the system will kick them both out. This has worked very well for me in the past, and when coupled with a method for IP address matching, it becomes even more secure. Essentially, if you need more security than this, I'd say it's time to add SSL into the mix. hope this helps! jpt -----Original Message----- From: Phillip Tyre [mailto:phillip.tyre@fcul.com] Sent: Friday, May 16, 2003 2:16 PM To: tallahassee-pm@mail.pm.org Subject: [Tallahassee-pm] PHP authentication Has anyone had any experience with a custom perl, or PHP based authentication framework using mysql as the back end? I've done some looking, but all the ones I've seen tend to make the same basic assumptions. Once you authenticate the user, and set a cookie, then you can trust all the cookies that are set for that user (admin status, username, etc). I'm really looking for something more secure, where the actual session table in the database would hold the permissions, and based on a matching session, the table would be queried to retrieve the permissions. Am I way off base on this? Phillip Tyre P.S. This message brought to you because of the heavy silence this list has experienced since the last time I posted. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/tallahassee-pm/attachments/20030516/a734b494/attachment.htm From JamesTillman at fdle.state.fl.us Fri May 16 13:57:04 2003 From: JamesTillman at fdle.state.fl.us (Tillman, James) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] PHP authentication Message-ID: <2265699E79C5D51197940002B31B4EDB06C00951@exchange.fdle.gov> Funny you mention AOL. That's the very reason we disabled the IP checking in my previous project. It was an internet-based project (not really the norm for my current client), and we kept getting folks complaining about getting kicked out! Good thinking on your part to avoid that altogether. As for your sessionid() function, I'd say it's practically worthy of appearing in a William S. Burroughs or Philip K. Dick novel. Plenty paranoid! jpt -----Original Message----- From: Phillip Tyre [mailto:phillip.tyre@fcul.com] Sent: Friday, May 16, 2003 2:43 PM To: tallahassee-pm@mail.pm.org Subject: RE: [Tallahassee-pm] PHP authentication That helps a ton. That is actually a lot like the system I was picturing, except you've obviously done a bit more thought on the expiration side of the problem. I'm very leery about coupling the system with client IP matching, just because of the poor sods on AOL and MSN, and all the fun proxy things both services do. SSL is a definite, but the problem that I worry about, but few others seem to, is the problem of a valid user executing a privilege escalation. And that is what most systems I see seem to leave wide open. Everyone who codes a website service seems to end up writing their own session system. Let me take that back, I've seen session systems that are supposed to be able to plug into anything you want to create, but again, they just don't seem that secure. There should be a nice, paranoid custom database driven session framework in open source, and then we could have a great time tying all the nice web services out there into the same backend without going insane. Speaking of paranoid, how's this? function sessionid() { // The purpose of this function is to generate a 110 digit, // case sensitive alphanumeric session ID for the purpose of // tracking active logins. It uses multiple entropy sources. // Generating large random numbers can be resource intensive, // So the upper limit of the random numbers can be tuned to // provide the right balance of uniqueness, and system performance. # Generate a unique ID based on the server clock $uid_clock=uniqid(1); # Generate a random number called $rand_num1 $rand_num1=rand(1, 1000000000000); # Generate a random number called $rand_num2 $rand_num2=rand(1, 1000000000000); # Calculate a md5 hash of each random number separately $rand_hash1= md5($rand_num1); $rand_hash2= md5($rand_num2); # Generate user_remote_info based on the client ip and port, if they exist. $user_remote_info = $_SERVER['REMOTE_ADDR'].$_SERVER['REMOTE_PORT']; # Calculate a hash based on the remote user info $user_remote_hash= md5($user_remote_info); # Combine the above hashes, and unique id's to create a relatively # unique and hard to guess string $nsessionid= $rand_hash1.$uid_clock.$rand_hash2.$user_remote_hash; return $nsessionid; } -----Original Message----- From: Tillman, James [mailto:JamesTillman@fdle.state.fl.us] Sent: Friday, May 16, 2003 1:31 PM To: Phillip Tyre; tallahassee-pm@mail.pm.org Subject: RE: [Tallahassee-pm] PHP authentication Yes, the silence has been unfortunate. I've been up to my ears in work these last few weeks. In my own previous work, I have been able to go a little further than simply setting a cookie in the browser and trusting it from then on. What I've done in the past with my own security systems was: * Create a large randomized string (20 chars min.) and use that value as a session key (I call it a "ticket"),which gets stored in the database as being tied to a particular user, and is then sent to the browser as a cookie along with another cookie indicating the username. * Each "ticket" has an expiration time of about 15 minutes (not an actual HTTP cookie expiration time, but a time my code keeps track of). This time can be as long or short as you want, depending on how paranoid you are. * Each time the browser accesses the web app, my server side code verifies that the cookie value matches the current ticket that is stored in the database for that user (or that is cached on the web server somehow -- it doesn't have to be a database, see Apache::Session), and that the "ticket" hasn't expired. * If the ticket has expired, a new one is generated, stored in the db, and issued to the browser without the user being any the wiser. * If an invalid ticket is passed in, all valid sessions for that user are deleted, and the user is asked to log in again. The end result is that it becomes very difficult for someone to hijack a user's session because they must be able to send in the usercode cookie and the ticket cookie, which is very hard to guess. Even if they manage to do that, they'll only get 15 minutes (or whatever I've set the expiry to be) before they blow up the session and force a login, since either their browser or the legitimate user's browser will send an invalid ticket once a new one gets issued and the system will kick them both out. This has worked very well for me in the past, and when coupled with a method for IP address matching, it becomes even more secure. Essentially, if you need more security than this, I'd say it's time to add SSL into the mix. hope this helps! jpt -----Original Message----- From: Phillip Tyre [mailto:phillip.tyre@fcul.com] Sent: Friday, May 16, 2003 2:16 PM To: tallahassee-pm@mail.pm.org Subject: [Tallahassee-pm] PHP authentication Has anyone had any experience with a custom perl, or PHP based authentication framework using mysql as the back end? I've done some looking, but all the ones I've seen tend to make the same basic assumptions. Once you authenticate the user, and set a cookie, then you can trust all the cookies that are set for that user (admin status, username, etc). I'm really looking for something more secure, where the actual session table in the database would hold the permissions, and based on a matching session, the table would be queried to retrieve the permissions. Am I way off base on this? Phillip Tyre P.S. This message brought to you because of the heavy silence this list has experienced since the last time I posted. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/tallahassee-pm/attachments/20030516/b503ae31/attachment.htm From jptillman at comcast.net Tue May 20 19:48:11 2003 From: jptillman at comcast.net (James Tillman) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] [Fwd: Newsletter from the O'Reilly UG Program, May 16] Message-ID: <1053478090.2665.16.camel@jacob.home> -------------- next part -------------- An embedded message was scrubbed... From: Marsee Henon Subject: Newsletter from the O'Reilly UG Program, May 16 Date: Fri, 16 May 2003 19:59:30 -0700 (PDT) Size: 12972 Url: http://mail.pm.org/pipermail/tallahassee-pm/attachments/20030520/6a81eeef/attachment.eml From phillip.tyre at fcul.com Thu May 29 12:58:03 2003 From: phillip.tyre at fcul.com (Phillip Tyre) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] Back on the wagon Message-ID: <39B5739894E97B40A427C59317BF2CD3878D8B@exchange2k.fcul.com> These last few weeks have seen me do some more light PHP coding, but yesterday, I actually broke down and worked in Perl some. To be honest, it's been a very long time since I created a program in Perl, but it just seemed the best option. It's just a little program that opens up a DBI connection, does some work, and then shuts down (It's going in a cron job once tested fully), but I'm rather proud of how quickly I got back up to speed and produced it. I also realize that when it comes to regular expressions in Perl, I'm still a weenie who can't make the plunge to using them comfortably. Maybe it's just lack of experience, but I always feel like I really don't know what I'm doing when I use them. For some reason I'm just intimidated by regular expressions, and I dunno why. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/tallahassee-pm/attachments/20030529/44641b01/attachment.htm From JamesTillman at fdle.state.fl.us Thu May 29 13:23:59 2003 From: JamesTillman at fdle.state.fl.us (Tillman, James) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] Back on the wagon Message-ID: <2265699E79C5D51197940002B31B4EDB06C009A5@exchange.fdle.gov> Heh, heh. Welcome back, errant Jedi knight! We won't fault you for falling to the dark side. By the way: PHP has added Perl5-compliant regular expressions to the language, so now you can feel intimidated in both languages! Frankly, PHP borrows so much from Perl's syntax and features, it should be an easy transition from one to the other. I've actually learned PHP by fixing other people's bugs, never having cracked a book on it. There's a great book from O'Reilly called "Mastering Regular Expressions". I'd recommend getting a trial subscription to O'Reilly Safari (if you haven't already), and read that book. You can use RegExps in many places, including many popular programmer's text editors, in Java (there are now 3 implementations in Java), Javascript on the client-side of all major web browsers, and God-only-knows-where-else. Once you learn 'em, you'll wonder how you ever did without 'em. jpt -----Original Message----- From: Phillip Tyre [mailto:phillip.tyre@fcul.com] Sent: Thursday, May 29, 2003 1:58 PM To: tallahassee-pm@mail.pm.org Subject: [Tallahassee-pm] Back on the wagon These last few weeks have seen me do some more light PHP coding, but yesterday, I actually broke down and worked in Perl some. To be honest, it's been a very long time since I created a program in Perl, but it just seemed the best option. It's just a little program that opens up a DBI connection, does some work, and then shuts down (It's going in a cron job once tested fully), but I'm rather proud of how quickly I got back up to speed and produced it. I also realize that when it comes to regular expressions in Perl, I'm still a weenie who can't make the plunge to using them comfortably. Maybe it's just lack of experience, but I always feel like I really don't know what I'm doing when I use them. For some reason I'm just intimidated by regular expressions, and I dunno why. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/tallahassee-pm/attachments/20030529/b8f2856b/attachment.htm From mexnix at craonline.org Thu May 29 14:37:42 2003 From: mexnix at craonline.org (Ryan Carmelo Briones) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] Back on the wagon References: <2265699E79C5D51197940002B31B4EDB06C009A5@exchange.fdle.gov> Message-ID: <001001c32619$c6ff16b0$874efea9@mexnix> Just adding a couple of things... make sure you pick up MRE v2 if you decide to get it. I hear it's a must have. Also, a guy i knew from perlmonks.org was starting to write a book for Manning, but it appears he never finished. None the less, what he had done is up at http://japhy.perlmonk.org/book/ . It is definitely worth checking out. This kid is a genius. Also, read your POD. It's there for a reason, and it has so much that we often overlook because of laziness. Just my $0.02. ------------------------------- ryan carmelo briones e: mexnix@craonline.org w: http://www.mexnix.org ----- Original Message ----- From: "Tillman, James" To: "'Phillip Tyre'" Cc: Sent: Thursday, May 29, 2003 2:23 PM Subject: RE: [Tallahassee-pm] Back on the wagon > Heh, heh. Welcome back, errant Jedi knight! We won't fault you for falling > to the dark side. > > By the way: PHP has added Perl5-compliant regular expressions to the > language, so now you can feel intimidated in both languages! > > Frankly, PHP borrows so much from Perl's syntax and features, it should be > an easy transition from one to the other. I've actually learned PHP by > fixing other people's bugs, never having cracked a book on it. > > There's a great book from O'Reilly called "Mastering Regular Expressions". > I'd recommend getting a trial subscription to O'Reilly Safari (if you > haven't already), and read that book. You can use RegExps in many places, > including many popular programmer's text editors, in Java (there are now 3 > implementations in Java), Javascript on the client-side of all major web > browsers, and God-only-knows-where-else. Once you learn 'em, you'll wonder > how you ever did without 'em. > > jpt > -----Original Message----- > From: Phillip Tyre [mailto:phillip.tyre@fcul.com] > Sent: Thursday, May 29, 2003 1:58 PM > To: tallahassee-pm@mail.pm.org > Subject: [Tallahassee-pm] Back on the wagon > > > These last few weeks have seen me do some more light PHP coding, but > yesterday, I actually broke down and worked in Perl some. To be honest, it's > been a very long time since I created a program in Perl, but it just seemed > the best option. It's just a little program that opens up a DBI connection, > does some work, and then shuts down (It's going in a cron job once tested > fully), but I'm rather proud of how quickly I got back up to speed and > produced it. > > I also realize that when it comes to regular expressions in Perl, I'm still > a weenie who can't make the plunge to using them comfortably. Maybe it's > just lack of experience, but I always feel like I really don't know what I'm > doing when I use them. For some reason I'm just intimidated by regular > expressions, and I dunno why. > From phillip.tyre at fcul.com Thu May 29 17:25:01 2003 From: phillip.tyre at fcul.com (Phillip Tyre) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] PDF's from a directory outside the server root Message-ID: <39B5739894E97B40A427C59317BF2CD3878D8E@exchange2k.fcul.com> An interesting problem I'm facing is trying to use a PHP page to serve a PDF file from a directory PHP has access to, but that APACHE does not. Take for example an expenses.pdf file that might be updated every month in the /home/accounting/ directory. I give PHP access to this directory, and want to serve the PDF via a PHP page. I've found examples of how to do this, and the following is the example of how I'm doing it. However, it doesn't work consistently well across different versions/ clients of IE. Ideally I'd like the PDF to just open in the browser when the PHP page is requested, hence my commenting of the attachment header. But on one client (XP with IE 6.2800), this actually produced a text view of the PDF file (all of the headers, all of the tags, escaped characters etc). And yes the client had a PDF viewer. Has anyone had any experience with this problem, or know of a good work around? Example PHP Script -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/tallahassee-pm/attachments/20030529/7c52f61d/attachment.htm From mexnix at craonline.org Thu May 29 17:56:53 2003 From: mexnix at craonline.org (Ryan Carmelo Briones) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] PDF's from a directory outside the server root References: <39B5739894E97B40A427C59317BF2CD3878D8E@exchange2k.fcul.com> Message-ID: <001801c32635$99dac780$874efea9@mexnix> i thought this was interesting, so i decided to check it out. after a couple different tries, i looked at what the php docs on the PDFLib had to say. [ http://www.php.net/manual/en/ref.pdf.php ] interestingly enough, there's an example ( search for "The script getpdf.php just returns the pdf document." ) that doesn't work as well. at least, _I_ couldn't get it to work. if this is for a company, you might think about buying the pdflib. if anything, it should be fun to work with. ------------------------------- ryan carmelo briones e: mexnix@craonline.org w: http://www.mexnix.org ----- Original Message ----- From: "Phillip Tyre" To: Sent: Thursday, May 29, 2003 6:25 PM Subject: [Tallahassee-pm] PDF's from a directory outside the server root An interesting problem I'm facing is trying to use a PHP page to serve a PDF file from a directory PHP has access to, but that APACHE does not. Take for example an expenses.pdf file that might be updated every month in the /home/accounting/ directory. I give PHP access to this directory, and want to serve the PDF via a PHP page. I've found examples of how to do this, and the following is the example of how I'm doing it. However, it doesn't work consistently well across different versions/ clients of IE. Ideally I'd like the PDF to just open in the browser when the PHP page is requested, hence my commenting of the attachment header. But on one client (XP with IE 6.2800), this actually produced a text view of the PDF file (all of the headers, all of the tags, escaped characters etc). And yes the client had a PDF viewer. Has anyone had any experience with this problem, or know of a good work around? Example PHP Script From mexnix at craonline.org Thu May 29 17:58:31 2003 From: mexnix at craonline.org (Ryan Carmelo Briones) Date: Mon Aug 2 21:37:58 2004 Subject: [Tallahassee-pm] PDF's from a directory outside the server root References: <39B5739894E97B40A427C59317BF2CD3878D8E@exchange2k.fcul.com> Message-ID: <002001c32635$d3ebe440$874efea9@mexnix> i stand correct. i decided to try one last thing, that worked! by golly. rock n roll ------------------------------- ryan carmelo briones e: mexnix@craonline.org w: http://www.mexnix.org ----- Original Message ----- From: "Phillip Tyre" To: Sent: Thursday, May 29, 2003 6:25 PM Subject: [Tallahassee-pm] PDF's from a directory outside the server root An interesting problem I'm facing is trying to use a PHP page to serve a PDF file from a directory PHP has access to, but that APACHE does not. Take for example an expenses.pdf file that might be updated every month in the /home/accounting/ directory. I give PHP access to this directory, and want to serve the PDF via a PHP page. I've found examples of how to do this, and the following is the example of how I'm doing it. However, it doesn't work consistently well across different versions/ clients of IE. Ideally I'd like the PDF to just open in the browser when the PHP page is requested, hence my commenting of the attachment header. But on one client (XP with IE 6.2800), this actually produced a text view of the PDF file (all of the headers, all of the tags, escaped characters etc). And yes the client had a PDF viewer. Has anyone had any experience with this problem, or know of a good work around? Example PHP Script