Oh. I get it. Thanks. I will definitely keep this in mind.

Best regards....

    Hi again,

    Any ideas why sessions would affect the posting of a form? The username and password inputs do not come through when submit is clicked :S

    Richard

      whats the code you are using. are you using session_start and assigning the $SESSION variables values from the $POST array?

        Hi there

        Its before I even put variables in the sessions that it is not working now - If i echo the variables they don't display, even though they worked fine when I was using cookies, so it can't be a fault in the form :S

          try print_r($_POST) and see what it displays.

            Just this:
            Array ( )

            In the script before I was just using $username etc to pick up the post data, but i've also tried $_POST["username"] and it doesn't work either

            Thanks once again
            Richard

              so then if you try getting rid of all session functions and variables in that script will the print_r once again result in showing data? if so post the code of both with and without session stuff and we can see if there are any small mistakes or if its really a strange behaviour. just out of curiousity, what php version is it you are using?

                I have now located the problem - It is not setting the sessions properly, or it is not reading them properly -

                Is this correct?
                session_start() - on the first page the user goes to

                $SESSION['username'] = $username;
                $                SESSION['loggedin'] = "Y";

                more code

                if (!isset($SESSION['loggedin'])||$SESSION['username']=="" || $getingt['isbanned']=="Y")
                {

                  session_start should be on every page that you will use a $_SESSION variable on.

                  my simple session test is this:

                  ses1.php

                  <?php

session_start();

if (!isset($_SESSION['count'])) {
  $_SESSION['count'] = 1;
} else {
  ++$_SESSION['count'];
}

echo $_SESSION['count'] . "<br />\n";

echo "<a href='ses2.php'>Page 2</a>";

?>

                  ses2.php

                  <?php

session_start();

echo $_SESSION['count']++;

echo "<br />\n<a href='ses1.php'>Page 1</a>";

?>

                  see if that basic example keeps incrementing the number for you.

                    I have now found out that the problem must be in the reading as it writes them successfully, as long as they are being carried through properly.

                      Woops me again - sorry and thanks for your help!
                      I think that the problem must be that the sessions aren't being carried through the pages correctly, because they echo on the same page as they were created, but on other pages. (When I pages i mean sections of the code, as a use ?Loc= for each page in one php file)

                      Many many thanks
                      Richard

                        Ah thank you I didnt see your post (#15)

                          IT WORKS!

                          Thank you soo much for your help! They say you learn something new each day...
                          I really can't be grateful enough
                          Thanks!

                            a month later
                            drew010 wrote:

                            you should at the least store an enctypted or hashed version of their password in a cookie and on each pageload make sure the password in the db matches up to the one in the cookie.

                            we may use several items in the match in addition to the password cookie. userid, user-email, user-password. userid and user-email are in plaintext in database, we can save them in cookie encrypted. password is already encrypted in the database, we can save the encrypted value directly, right?

                            the whole idea for the saving the encrypted value in cookie is that for prevent attackers who sign in as your user, and then analysis the cookie and then try to break into other users account, right?

                            if the clients computer is attacked by the attackers and his cookie is grabbed by the attacker, then encrypted or not encrypted cookie values, will that still make difference?

                            or with not encrypted cookie value, the attacker could sign in from his computer, but with encrypted value, the attacker has to pretend to sign in from the victim's computer? so encrypted cookie value still add a layer of the protection here?

                            drew010 wrote:

                            sessions are also an okay idea, but by default a session ends when the browser is closed so unless you dont mind people logging in each time they come on you could use some sort of session authentication.

                            How about session fixation attack? PHP cookie is also under the "session fixation attack", or php cookie cannot be attacked by session fixation attack?

                            session id is a cookie, the when session fixation attack get your session id, does it mean it get your cookie, so php cookie is also attacked by session fixation attack method?

                            in the manual, session chapter has mentioned the session fixation attack. but cookie chapter doesn't, even cookie could set up to have a life time as session, but cookie has nothing to do with the session (or session fixation attacks)?

                            How session and cookie works in php? is using cookie a alternate approach to prevent session fixation attacks?

                            Thanks!

                              Write a Reply...