Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 7 of 7
  1. #1
    Regular Coder nomanic's Avatar
    Join Date
    Feb 2009
    Location
    United Kingdom
    Posts
    255
    Thanks
    9
    Thanked 33 Times in 33 Posts

    server migration issue

    Hi

    I created a website on one server, fixed all bugs, it all worked fine
    So we uploaded it to clients server
    Now its full of errors
    I am using cookies to store session variables
    and I believe all the bugs are to do with cookies not being set properly
    another thing -
    getimagesize on remote images doesnt work
    so I thought this must be something to do with php ini settings being different on the 2 servers
    so I set up a phpinfo page on each server

    server where it works-
    http://www.paulhaneysax.net/phpinfo.php

    server where it doesnt work-
    http://www.koreafilm.eu/phpinfo.php

    for instance I thought the getimagesize was allow_url_fopen not being enabled
    but seems this is enabled on both servers

    To me both phpinfos with regards to relevant info seem the same
    anyone have any ideas? I just dont get why it doesnt work on their server?

    Many thanks,
    Neil
    <DmncAtrny> I will write on a huge cement block "BY ACCEPTING THIS BRICK THROUGH YOUR WINDOW, YOU ACCEPT IT AS IS AND AGREE TO MY DISCLAIMER OF ALL WARRANTIES, EXPRESS OR IMPLIED, AS WELL AS DISCLAIMERS OF ALL LIABILITY, DIRECT, INDIRECT, CONSEQUENTIAL OR INCIDENTAL, THAT MAY ARISE FROM THE INSTALLATION OF THIS BRICK INTO YOUR BUILDING."
    <DmncAtrny> And then hurl it through the window of a Sony officer
    <DmncAtrny> and run like hell

    Portfolio, Tutorials - http://www.nomanic.biz/

  • #2
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,439
    Thanks
    62
    Thanked 537 Times in 524 Posts
    Cookies are cookies no matter what so I doubt they are failing to be set but remember that forum issue I helped you out with a while back? You said it didn't work right? Thats because you had old stale cookies set for that domain. Cookies are beasts to use sometimes so when experimenting and writing your code always remember to wipe the little critters otherwise you can run into some odd hassles.

    As for the image stuff, looking at the phpinfo and scrolling down to gd I did notice the Freetype versions were different. On the working server its 2.21 and on the new server its 2.3.11. No idea if that would be the cause but there is an instant difference straight away. Now, getimagesize() is part of the GD library so I suspect this may actually be part of the problem though I can't confirm for 100% but that may give you enough of a pointer to be on the road to recovery.

    Of course, you could always show us some code
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!

  • #3
    Regular Coder nomanic's Avatar
    Join Date
    Feb 2009
    Location
    United Kingdom
    Posts
    255
    Thanks
    9
    Thanked 33 Times in 33 Posts
    hi tangoforce!

    happy new year!
    happy to show code
    but have no idea whats relevant
    with regards to getimagesize, its straightforward enough
    pass it a local image "images/picture.jpg" it works fine
    pass it a remote image "http://www.google.com/images/picture.jpg" and it returns false
    this is even when its the same image in question, just web address and local address used
    with regard to cookies, it seems to be storing session variables, which are cookies, and I've just gone back to the page now, and it remembered my settings, which should be cookies
    but if it works perfectly on one server, and not on another, that must be ini settings/php version right?
    <DmncAtrny> I will write on a huge cement block "BY ACCEPTING THIS BRICK THROUGH YOUR WINDOW, YOU ACCEPT IT AS IS AND AGREE TO MY DISCLAIMER OF ALL WARRANTIES, EXPRESS OR IMPLIED, AS WELL AS DISCLAIMERS OF ALL LIABILITY, DIRECT, INDIRECT, CONSEQUENTIAL OR INCIDENTAL, THAT MAY ARISE FROM THE INSTALLATION OF THIS BRICK INTO YOUR BUILDING."
    <DmncAtrny> And then hurl it through the window of a Sony officer
    <DmncAtrny> and run like hell

    Portfolio, Tutorials - http://www.nomanic.biz/

  • #4
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,439
    Thanks
    62
    Thanked 537 Times in 524 Posts
    Quote Originally Posted by nomanic View Post
    hi tangoforce!

    happy new year!
    And to you matey

    Quote Originally Posted by nomanic View Post
    pass it a local image "images/picture.jpg" it works fine
    pass it a remote image "http://www.google.com/images/picture.jpg" and it returns false
    Ok, try grabbing it into a variable via file_get_contents() then and then passing the variable to getimagesize() instead. Remember to verify that you've got the file first though.

    Quote Originally Posted by nomanic View Post
    this is even when its the same image in question, just web address and local address used
    So it may well be to do with the way the file is being grabbed. Try my above suggestion and see if this provides any clues or fixes.

    Quote Originally Posted by nomanic View Post
    with regard to cookies, it seems to be storing session variables, which are cookies, and I've just gone back to the page now, and it remembered my settings, which should be cookies
    but if it works perfectly on one server, and not on another, that must be ini settings/php version right?
    I'm slightly confused what you're getting at here. Session variables are stored only in the session file on the server. The cookie on the users computer is used purely to store the unique session identifier (similar to a 32bit MD5 hash). That is all that a session puts into a cookie. Anything you put into the $_SESSION array is actually stored in a serialized file on the servers hard disk. When you call session_start() it opens and reads out the serialized array and puts it into the $_SESSION array for you. Obviously this session data will not be available on another physical server. Cookies are generally used for remembering user preferences that you want your site to be able to access if the session has expired. They're a PITA if you ask me so its a good job that php sessions only use one.
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!

  • Users who have thanked tangoforce for this post:

    nomanic (01-02-2013)

  • #5
    Regular Coder nomanic's Avatar
    Join Date
    Feb 2009
    Location
    United Kingdom
    Posts
    255
    Thanks
    9
    Thanked 33 Times in 33 Posts
    I'll try the file_get_contents

    good work around

    I read about secure logins, most of the code was just copied rather than understood, but basically it said to stop session hijacking, store the session variables in cookies, I was led to believe thats what it does. I appreciate I use lots of session variables, there wouldnt be enough cookies, but took it as read.

    This might be down to the browser blocking the cookies, rather than the PHP, in which case site falls over. But I'll have to investigate this further, gonna try the file_get_contents though

    Thankyou Tangoforce!
    <DmncAtrny> I will write on a huge cement block "BY ACCEPTING THIS BRICK THROUGH YOUR WINDOW, YOU ACCEPT IT AS IS AND AGREE TO MY DISCLAIMER OF ALL WARRANTIES, EXPRESS OR IMPLIED, AS WELL AS DISCLAIMERS OF ALL LIABILITY, DIRECT, INDIRECT, CONSEQUENTIAL OR INCIDENTAL, THAT MAY ARISE FROM THE INSTALLATION OF THIS BRICK INTO YOUR BUILDING."
    <DmncAtrny> And then hurl it through the window of a Sony officer
    <DmncAtrny> and run like hell

    Portfolio, Tutorials - http://www.nomanic.biz/

  • #6
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,439
    Thanks
    62
    Thanked 537 Times in 524 Posts
    Quote Originally Posted by nomanic View Post
    I read about secure logins, most of the code was just copied rather than understood, but basically it said to stop session hijacking, store the session variables in cookies, I was led to believe thats what it does. I appreciate I use lots of session variables, there wouldnt be enough cookies, but took it as read.
    No not really. Anything that is stored in a cookie can be hijacked - thats the very nature of the darn things. They're transmitted as a line of text in the reply headers and consequently with every new http request back to that domain they're sent back as a line of text in the request headers. Anyone using a packet sniffer to monitor you or your users can sniff these cookies from your http headers unless the site is used over SSL but even that can be cracked by those who really know what they're doing. Cookies are also domain dependant. That means if you set a cookie called username on domainA.com and then try to read that cookie by its name on domainB.com it won't exist - the browser will not have sent it to domainB.com in the request headers - thats just the way it works.

    When you use a PHP session, php adds a header to your reply headers that are sent to the browser with the php session name (by default its PHPSESSID) and then a long string of random numbers and letters. THAT is how php identifies the users session between page views - the browser sends back that value with every request and PHP uses it to open the correct session file on the servers hard drive.

    Using cookies for individual pieces of information is pointless especially from a security POV. Say for instance you set a cookie with a user id or username. Anyone who can sniff the http connection could steal that cookie and use it themselves and your site wouldn't know the difference between them (unless you did IP checks etc but those can be spoofed). Cookies really should only be used for basic stuff like the users preference of a page background colour (and then those can be read with javascript instead of being relied on at the server side).

    I supose what I'm really saying is: Cookies - avoid like the plague and let PHP do it's own internal session cookie thing itself.
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!

  • #7
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,439
    Thanks
    62
    Thanked 537 Times in 524 Posts
    Just a bit of an update really about the cookie process.

    I have a program I made that I use for testing http connections / cookies / html output etc. It's not quite finished but it does the job well enough for me to test things out.

    Now, when you make a request to a website (lets say codingforums.com) the server will send cookies to your browser. As you can see, codingforums sends 3 cookies to the browser:



    Now, when you originally make that first request, this is what happens:



    Notice the request headers at the top. This is your browser making a request to the server. It then sends a blank line to indicate that is the end of the request. In return the server then sends its reply headers, a blank line (so the browser knows the headers have ended) followed by the html.

    If you look carefully at the reply headers in the second image you will see the 3 cookies being sent as text:
    Set-Cookie: bbsessionhash=442e4a026c178ee1d53f6ff9b4c1e315; path=/; HttpOnly<EOL>
    Set-Cookie: bblastvisit=1357140373; expires=Thu, 02-Jan-2014 15:26:13 GMT; path=/<EOL>
    Set-Cookie: bblastactivity=0; expires=Thu, 02-Jan-2014 15:26:13 GMT; path=/<EOL>
    As you can see, the cookies are sent in a similar format to an ini file - name=value; plus_some_other_bits. Because they are text being sent over the same connection those can easily be seen by anyone that is monitoring your http connection. The cookie files you see on your PC in your history are actually created by your browser which then puts the cookie information into them. The site doesn't actually send any file at all, just the actual information.

    Right so the cookies are sent, what are they? Well as you can see from the first one, there is a session hash. Thats basically how the forum knows who you are - it will use that cookie to find your session data file on the servers hard drive and read out all of the session variables such as your username and security permissions etc. The next two are self explanatory - your last time of visit and activity from the current computer you're using - different from another computer that you may have visited from.

    Anyway, naturally being a forum, you're going to click a link somewhere right? So by browsing into the php forum (forumdisplay.php?f=6) this is what happens:



    Look at the request headers at the top - you will see that the browser (in this case my program) is sending back the cookie names and values to the site:

    Sent: GET /forumdisplay.php?f=6 HTTP/1.1<EOL>
    Host: www.codingforums.com<EOL>
    Accept: text/html, */*<EOL>
    User-Agent: Mozilla/3.0 (compatible; Indy Library)<EOL>
    Cookie: bblastactivity=0; bblastvisit=1357140373; bbsessionhash=442e4a026c178ee1d53f6ff9b4c1e315<EOL>
    <EOL>
    Thats pretty much it! The server receives the headers and passes them to php which then makes those cookies available in the $_COOKIE array to the script. The script can then use those values to lookup data in a database or a session file. Again because the cookies were sent by a TCP connection as text, they can be monitored, stolen and used by anyone with ease.

    The bottom line is that using cookies for authentication and storing sensitive data isn't a good idea. Store it in the session and let php use a session cookie (automatically - you don't need to worry about it) to determine who is who. At that point you might want to check the users IP matches and prompt them to confirm their password but you should be a bit safer than storing everything in cookies!
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!


  •  

    Posting Permissions

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