SitePoint Sponsor

User Tag List

Page 1 of 12 1234511 ... LastLast
Results 1 to 25 of 295
  1. #1
    SitePoint Zealot
    Join Date
    Jan 2002
    Location
    london
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Managing Users with PHP Sessions and MySQL

    hi folks

    i read kevin yank's article Managing Users with PHP Sessions and MySQL, it is very interesting but i have one problem.

    kevin says to use a php.ini file to include certain bits of code. i have spoken with my hosting company and they say they dont allow me access to the php.ini file on the server but i can create an .htaccess file. is there a way to achieve the same results using .htaccess instead?

    thanks

    A
    give me all your lentils

  2. #2
    SitePoint Evangelist galt's Avatar
    Join Date
    Apr 2002
    Posts
    461
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Several comments here recently about this. Try a search on htaccess.

  3. #3
    SitePoint Addict itsource's Avatar
    Join Date
    Jun 2001
    Location
    Thailand
    Posts
    369
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You don't need to edit php.ini file.

    for include file, use can paste include file in the same directory of your php file and use

    include "/home/yourpath/include.inc.php";
    I live in Thailand. My English grammar not well.

  4. #4
    SitePoint Zealot
    Join Date
    Jan 2002
    Location
    london
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi guys, thanks for your replies,

    itsource: the reason i was asking was because kevin seems to suggest that putting the include files in your web directory is not secure in the event that php stops working on the server....

    In either case, you can choose to put your include files in the same directory as the file(s) that use them, or place them in the appointed directory. The latter choice is a safer for files containing sensitive information like passwords, because if the PHP support in your Web server ever fails, the information in PHP files not stored below your server's Web root directory will not be exposed to prying eyes.
    give me all your lentils

  5. #5
    SitePoint Author Kevin Yank's Avatar
    Join Date
    Apr 2000
    Location
    Melbourne, Australia
    Posts
    2,571
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Lentildal,

    Your hosting company is right -- you can modify PHP's include directory setting (normally configured in php.ini) with an .htaccess file in your site's root directory.

    Just create a text file called .htaccess in the root directory of your site that contains one line like the following:
    Code:
    php_value include_path .:/path/to/includes
    where /path/to/includes is the full path to the directory outside your Web root where you want to store your PHP include files.

    Of course, with a reputable hosting company it's fairly unlikely that they'll ever break PHP support and expose your scripts to the world, but you can never be too careful.
    Kevin Yank
    CTO, sitepoint.com
    I wrote: Simply JavaScript | BYO PHP/MySQL | Tech Times | Editize
    Baby’s got back—a hard back, that is: The Ultimate CSS Reference

  6. #6
    SitePoint Zealot
    Join Date
    Jan 2002
    Location
    london
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    hey kevin, thanks for replying

    dont i need to be able to open the php.ini file and paste in my php scripts to use it?

    my host said they wouldnt allow me access to the php.ini file.

    btw - thought your article was v. good

    thanks

    L
    give me all your lentils

  7. #7
    SitePoint Evangelist galt's Avatar
    Join Date
    Apr 2002
    Posts
    461
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is there something wrong with the Sitepoint forums? I seem to remember this whole thread from two days ago. almost verbatim. It's deja vu all over again. Was I hallucinating? I wonder if I know what Saturday's Lotto numbers are going to be?

  8. #8
    SitePoint Author Kevin Yank's Avatar
    Join Date
    Apr 2000
    Location
    Melbourne, Australia
    Posts
    2,571
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    L,

    You don't need to put any code in your php.ini file, no. What gave you the impression that you did?
    Kevin Yank
    CTO, sitepoint.com
    I wrote: Simply JavaScript | BYO PHP/MySQL | Tech Times | Editize
    Baby’s got back—a hard back, that is: The Ultimate CSS Reference

  9. #9
    SitePoint Zealot
    Join Date
    Jan 2002
    Location
    london
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    er....where do i put the include files then?

    lets take "db.php" for example, with all my database details, which directory do i put that in?

    also a little further into the article you talk about changing the following options:

    session.save_handler = files
    session.save_path = C:\WINDOWS\TEMP
    session.use_cookies = 1

    do these not reside within the php.ini file?

    thanks, sorry if im being a bit simple.

    Lentil
    give me all your lentils

  10. #10
    SitePoint Author Kevin Yank's Avatar
    Join Date
    Apr 2000
    Location
    Melbourne, Australia
    Posts
    2,571
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    The include files, as I explain in the article, should go in a directory on your Web server that is outside your Web site's directory structure. So for example if your Web site is in /home/lentildal/httpdocs, a good place for your include files would be in /home/lentildal/phpincludes. You'd then use the .htaccess file as I described above to add that directory to the PHP include_path.

    Note that in a shared server scenario, you do NOT want to add the include_path change to the global php.ini file, as it would allow other users with sites on the system to run your include files as part of their scripts.

    As for the session configuration parameters, those should indeed go in the php.ini file, but if your Web host has set up PHP for you then this has been done already.
    Kevin Yank
    CTO, sitepoint.com
    I wrote: Simply JavaScript | BYO PHP/MySQL | Tech Times | Editize
    Baby’s got back—a hard back, that is: The Ultimate CSS Reference

  11. #11
    SitePoint Zealot
    Join Date
    Jan 2002
    Location
    london
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ah, i see now

    thanks for taking the time to explain

    btw - could you point me in the direction of any tutorials or posts that would enable me to add a log feature to this script, to capture the username and time/date that anyone logged in and out, maybe just save them to a text file on the server?

    thanks very much

    ..L
    Last edited by lentildal; May 10, 2002 at 01:24.
    give me all your lentils

  12. #12
    SitePoint Evangelist
    Join Date
    Dec 2000
    Posts
    528
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Storing Passwords in a MySQL Database

    Hi all,

    I just read Kevin Yank's article on managing users with PHP and MySQL, and have one question.

    Kevin says,
    Of course, you can't store the passwords encrypted using MySQL's PASSWORD function if you want to implement this feature (since PASSWORD is a one-way operation that cannot be reversed).

    http://www.webmasterbase.com/article/319/119
    So how can I encrypt users' passwords but then be able to "un-encrypt" them to email them to the user in case they forget their passwords?

    Thanks,
    Corbb
    Corbb O'Connor
    Looking for quality website design or database programming?
    Contact me for more information and a FREE quote!

  13. #13
    SitePoint Wizard silver trophy TheOriginalH's Avatar
    Join Date
    Aug 2000
    Location
    Thailand
    Posts
    4,810
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    Re: Storing Passwords in a MySQL Database

    Originally posted by JustForWebmasters
    Hi all,

    I just read Kevin Yank's article on managing users with PHP and MySQL, and have one question.

    Kevin says,So how can I encrypt users' passwords but then be able to "un-encrypt" them to email them to the user in case they forget their passwords?

    Thanks,
    Corbb
    You don't have to. If they can remember their username then you can have a "reset your password" email sent to their registered address with a link to a form that carries out an update, without ever reading the data...
    ~The Artist Latterly Known as Crazy Hamster~
    922ee590a26bd62eb9b33cf2877a00df
    Currently delving into Django, GIT & CentOS

  14. #14
    SitePoint Evangelist
    Join Date
    Dec 2000
    Posts
    528
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi OriginalH,

    So then their password would just be radmonly re-generated?

    Thanks,
    Corbb
    Corbb O'Connor
    Looking for quality website design or database programming?
    Contact me for more information and a FREE quote!

  15. #15
    SitePoint Author Kevin Yank's Avatar
    Join Date
    Apr 2000
    Location
    Melbourne, Australia
    Posts
    2,571
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    That's correct.
    Kevin Yank
    CTO, sitepoint.com
    I wrote: Simply JavaScript | BYO PHP/MySQL | Tech Times | Editize
    Baby’s got back—a hard back, that is: The Ultimate CSS Reference

  16. #16
    SitePoint Evangelist
    Join Date
    Dec 2000
    Posts
    528
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks Kev!

    -Corbb
    Corbb O'Connor
    Looking for quality website design or database programming?
    Contact me for more information and a FREE quote!

  17. #17
    SitePoint Enthusiast
    Join Date
    Jun 2002
    Posts
    55
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't understand why the script has to set register_session first before checking if the user is valid in database?

    Why not just check if the user is valid first, then only set register_session?


    Thanks,

    Truong.

  18. #18
    SitePoint Evangelist
    Join Date
    Dec 2000
    Posts
    528
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    From my understanding, I believe that it's a speed thing. It's faster to check register_session than to check the database. Maybe...not quite sure...
    Corbb O'Connor
    Looking for quality website design or database programming?
    Contact me for more information and a FREE quote!

  19. #19
    SitePoint Author Kevin Yank's Avatar
    Join Date
    Apr 2000
    Location
    Melbourne, Australia
    Posts
    2,571
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    The reasoning is as follows...

    There are four situations in which this script may be run:
    1. No session yet exists. The user has filled in the login form with a valid username/password.
    2. No session yet exists. The user has filled in the login form with an invalid username/password.
    3. The session is in place, with a valid username/password stored in it.
    4. The session is in place, but the username/password stored in it is no longer valid (e.g. the account was removed while the user was logged in).
    To handle these four situations, you can choose from two algorithms:

    Algorithm 1
    Begin/Restore Session.
    (Re)register the variables.
    Validate the user/pass.
    If invalid {
    Unregister the variables.
    Show access denied.
    Exit.
    }
    Display content.

    Algorithm 2
    Begin/Restore the Session.
    Validate the user/pass.
    If Invalid {
    If vars registered, unregister them.
    Show access denied.
    Exit.
    }
    (Re)register variables.
    Display content.

    The article uses Algorithm 1. Truong, you have proposed Algorithm 2. Both will work. At the time I wrote the article, I decided that #1 was tidier. Yes, it needlessly registers the variables if the values are invalid, but that saves the script having to check if the variables are registered before unregistering them.

    I believe #1 is tidier because you can re-register session variables in PHP without it complaining, but if you try to un-register variables that aren't registered you'll get warning messages. It's been awhile, though, so that may have changed now.
    Kevin Yank
    CTO, sitepoint.com
    I wrote: Simply JavaScript | BYO PHP/MySQL | Tech Times | Editize
    Baby’s got back—a hard back, that is: The Ultimate CSS Reference

  20. #20
    SitePoint Member
    Join Date
    Sep 2002
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Angry Where do I reference the database name?

    I like the article...but I was unable to figure out where I add the db name?

    I appreciate any help on this...Thanks

  21. #21
    SitePoint Member
    Join Date
    Sep 2002
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Where do I reference the database name?

    Now I'm getting:

    Warning: Cannot send session cache limiter - headers already sent (output started at /home/mysite/public_html/php/accesscontrol.php:7) in /home/mysite/public_html/php/accesscontrol.php on line 12

    in
    accesscontrol.php
    and
    signup.php

    I am using
    dbConnect("db_name");
    instead of Kevin's original
    dbConnect("sessions");


    Line 7 starts as fllows
    <?php // accesscontrol.php

    include("common.php");
    include("db.php");

    session_start();

    if(!isset($uid)) {
    php?>


    SO line 12 is
    session_start();

    I am confused...Yes I am...Help! Thank You!


    Originally posted by UncleSam
    I like the article...but I was unable to figure out where I add the db name?

    I appreciate any help on this...Thanks

  22. #22
    SitePoint Wizard Aes's Avatar
    Join Date
    Jun 2001
    Location
    Oklahoma
    Posts
    3,392
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Could you please post the code where you define dbConnect()?

    -Colin
    Colin Anderson
    Ambition is a poor excuse for those without
    sense enough to be lazy.

  23. #23
    SitePoint Member
    Join Date
    Sep 2002
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    I fixed it...

    OK...by reading a little bit more...and trying a couple of thing...it is now working.

    I had to make one variation to the original code:

    I moved the
    session_start();
    in accesscontrol.php file to make it 1st line.

    Thanks a Lot Colin for trying, but the original function works! and Thanks Kevin!

    UncleSam

  24. #24
    SitePoint Member
    Join Date
    Sep 2002
    Posts
    10
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Smile As to the database name:

    By the way, to make things work,

    I had to also change Multiple occurences:

    from
    dbConnect("sessions");

    to:
    dbConnect("db_name");

    Works great!

    UncleSam

  25. #25
    SitePoint Author Kevin Yank's Avatar
    Join Date
    Apr 2000
    Location
    Melbourne, Australia
    Posts
    2,571
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Looks like you figured it all out. The error message you were getting occurs when PHP has already sent some HTML or other content to the browser when you call session_start(). Since accesscontrol.php shouldn't have had any output instructions or code outside the <?php ?> tags before session_start(), I'd have expected the problem to be in the file where you included accesscontrol.php. If that include didn't occur on the very first line of the file, or if there were any spaces or line breaks before the opening <?php of the include, that would explain the error you were getting.

    But as I said, it sounds like you figured it out for yourself.
    Kevin Yank
    CTO, sitepoint.com
    I wrote: Simply JavaScript | BYO PHP/MySQL | Tech Times | Editize
    Baby’s got back—a hard back, that is: The Ultimate CSS Reference


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •