Jump to content

php_guy

Members
  • Posts

    62
  • Joined

  • Last visited

    Never

Profile Information

  • Gender
    Not Telling

php_guy's Achievements

Member

Member (2/5)

0

Reputation

  1. Hello all, I am trying to make a document repository for my a group of people on my website. The problem is, I only want people with "membership" (i.e. that enter a correct user/pwd) to be able to get access to this page and download the files. Normally in PHP we can use Sessions to create a login process -- that is not the problem. The problem is that if someone knows the direct link to the file, they can send it to a friend (who is not a member) and they can download the file without being able to log in. For example, let's say an authenticated user John logs in and copies the link location of a particular MS-Word file. This link will allow anyone to download the file. How can I prevent that? Thanks
  2. Hey guys, I've been trying a lot of things, and finally got it to work.... I'll try and remember what I did in case anyone runs into this in the future: First, I'm running debian so it was recommended to use exim instead of sendmail explicitly... So I did apt-get install exim4-base. I think this must have replaced the symbolic link for /usr/sbin/sendmail to exim after I did this. Anyway, I tried to run my PHP page agian. No luck Then I tried to run sendmail directly from the command line and I got the error: "Mailing to remote domains not supported " So I googled that error and found someone else had a similar problem here: http://himerus.com/blog/himerus/mailing-remote-domains-not-supported-debian-lenny I had to run: dpkg-reconfigure exim4-config and choose "internet site; mail is sent and received directly using SMTP". I took the defaults for the other settings. This is also explained here: http://www.electrictoolbox.com/changing-exim4-settings-debian-5-lenny/ Whew! What an epic journey and I hope this is solved... I will continue to test
  3. Well, I just read that Perl's Mail function (at least the one that I used) does not use sendmail Does Mail::Sendmail need a command-line sendmail? No. It communicates directly with any local or remote SMTP server using only Perl sockets. This was actually it's primary "raison d'ĂȘtre". Source: http://alma.ch/perl/Mail-Sendmail-FAQ.html That explains why it works on Perl. I mean, I could always use PHP's PEAR or another Mail api thta does not use sendmail, but I would rather try to get sendmail to work... At this point, it seems to be a problem with sendmail, since sendmail at the command line does not work. Has anyone run into this before?
  4. I'm not sure if you're familiar with Perl... But this perl code -- on the same machine -- takes about a second to send.... compared to the PHP code and sendmail command line which take forever #!/usr/bin/perl -T #!/usr/bin/perl -Tw use strict; use CGI; use Mail::Sendmail; my %mail = ( To => "me\@domain.com", From => "The Perl Agent <perl\@domain.com>", Subject => "Perl Mail", Message => "Just the message body", smtp => 'mail.isp.com', 'Content-Type' => 'text/html; charset=iso-8859-1' ); sendmail(%mail); # or die $Mail::Sendmail::error; print "Content-type: text/html\n\n"; print "<html><body>"; print "OK. Log says:\n", $Mail::Sendmail::log; print "</body></html>"; Presumably they use the same method to send mail, no?
  5. I just tried sendmail alone on the command line: sendmail -v me@domain.com < test.mail Where test.mail is Subject: test mail Some test And it still takes long... maybe the problem is with my sendmail itself?
  6. Hi Ken Here's my code ini_set("SMTP", "mail.isp.com"); $to = "myaddress@domain.com"; $subject = "PHP Sendmail Example"; $headers = "From: The Root Monster <bigbadroot@domain.com>\r\n" . "Reply-To: bigbadroot@domain.com\r\n" . "Content-type: text/html; charset=iso-8859-1\r\n"; $body = "This is a sample message -- Why does it take so long"; if( mail($to,$subject,$body,$headers) ) echo "success!"; else echo "nope! nope!"; I WAS able to get things working by doing apt-get install sendmail-bin apt-get install sendmail ... But the mail takes so LONG to send! Normally it takes a second tops, but this is taking close to a minute. When I say, "takes long to send" i mean the actual php page takes almost a minute to respond (the task bar says "Waiting for domain....") and the output ("success!") is not printed for about a minute. Any idea what it could be that's taking so long?
  7. FYI I've tried changing the sendmail configuration the following as well, to no avail sendmail_path = "/usr/sbin/sendmail -t" sendmail_path = "/usr/sbin/sendmail -t -i" Same result, the code returns true, but I don't receive any email. I've tried different email addresses to see if it's a problem with my particular one (which, like I said, it shouldn't, I've used Perl to send an email fine on the same machine)
  8. Hello all, I am trying to get PHP's mail() function to work, but it's not. I'm just using a basic mail() example that I've used on other servers -- it works fine. I've tried... 1) Setting the SMTP to the correct SMTP server in PHP ini file and using ini_set() 2) The port is correctly set to 25 3) I've set the sendmail path in PHP.INI to ; For Unix only. You may supply arguments as well (default: "sendmail -t -i"). ; http://php.net/sendmail-path sendmail_path = /usr/sbin/sendmail -t The mail() function returns true, however it's not working! I know it's not something with my machine blocking ports because I can use Perl and it works fine Any ideas?
  9. I have the following 1. php page that stores sessions. press submit and... 2. ...goes to perl/cgi page to interface with an api only available in perl, then auto redirects via HTTP headers to... 3. ... a php page where depending on the result a field is added to database then emailed, etc... then... 4.... redirects to main page so really all the user sees is page 1 -> hits submit -> ends up on page 4 via redirects Is there a problem with using redirects? Could the user intervene and prevent these redirects? Thanks
  10. I am using a sloppy 3rd party API that doesn't return error codes, just error messages. See below $err = $object->getErrorMessage(); if( strlen($err) > 0 ) { header("Location: step1.php?err=$err"); } As you can see this is sloppy because anyone can just modify the address bar of step1.php and inject their own error message, or javascript or their own HTML buttons, etc. As a work around, I thought maybe I could use POST instead of GET... At least then the "err" variable would be hidden for the most part Any ideas how I can work around this? Thanks!
  11. Hello all, I've recently upgraded some php binaries on my machine (as well as other files from my distro), and now my PHP files are downloading, rather than being parsed by Apache Here is the output of php -v juptier:/home# php -v PHP Deprecated: Comments starting with '#' are deprecated in /etc/php5/cli/conf.d/mysql.ini on line 1 in Unknown on line 0 PHP Deprecated: Comments starting with '#' are deprecated in /etc/php5/cli/conf.d/mysqli.ini on line 1 in Unknown on line 0 PHP Deprecated: Comments starting with '#' are deprecated in /etc/php5/cli/conf.d/pdo_mysql.ini on line 1 in Unknown on line 0 PHP Deprecated: Comments starting with '#' are deprecated in /etc/php5/cli/conf.d/pspell.ini on line 1 in Unknown on line 0 PHP Deprecated: Comments starting with '#' are deprecated in /etc/php5/cli/conf.d/xmlrpc.ini on line 1 in Unknown on line 0 PHP Deprecated: Comments starting with '#' are deprecated in /etc/php5/cli/conf.d/xsl.ini on line 1 in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626+lfs/mysql.so' - /usr/lib/php5/20090626+lfs/mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626+lfs/mysqli.so' - /usr/lib/php5/20090626+lfs/mysqli.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626+lfs/pdo_mysql.so' - /usr/lib/php5/20090626+lfs/pdo_mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626+lfs/pspell.so' - /usr/lib/php5/20090626+lfs/pspell.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626+lfs/xmlrpc.so' - /usr/lib/php5/20090626+lfs/xmlrpc.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626+lfs/xsl.so' - /usr/lib/php5/20090626+lfs/xsl.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP 5.3.5-0.dotdeb.1 with Suhosin-Patch (cli) (built: Jan 11 2011 10:40:15) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH juptier:/home# Any idea how to fix this? Thanks
  12. Ahhhhh I KNEW there was a cleaner way than just hidden fields How secure are sessions? And would it just be a matter of doing: $_SESSION['myfield'] = myvalue? Besides the user clicking the close button of the browser, when are session variables destroyed? Thanks
  13. I have an ordering process that consists of 3 pages: 1) Page1: Enter name/address 2) Page2: Based on address, determine availability of products, and let user choose which products, how many, etc. 3) Page3: Enter credit card info to send to the processor What is the best way to store information fro page 1 to page 2, then from page 2 to page 3? I thought about just using hidden fields. Is this OK? Is there another preferred way? Thanks!
  14. Ahhhh that makes sense, and sounds very thorough. So basically program your PHP as if there is no Javascript -- but optionally include the javascript anyway, as a means to reduce server hits for something as simple as a missing field (but don't rely solely on this) Is that sort of the rationale? Thanks
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.