Jump to content

PFMaBiSmAd

Staff Alumni
  • Posts

    16,734
  • Joined

  • Last visited

  • Days Won

    9

PFMaBiSmAd last won the day on May 28 2014

PFMaBiSmAd had the most liked content!

About PFMaBiSmAd

Profile Information

  • Gender
    Not Telling
  • Location
    Colorado, U.S.A.

Recent Profile Visitors

19,773 profile views

PFMaBiSmAd's Achievements

Advanced Member

Advanced Member (4/5)

131

Reputation

  1. Since we are bumping this (already solved) thread - a solution using mktime/date has already been posted and it's been pointed out that using mktime/date doesn't work for people born before 1970 or 1901 (depending on php version and 32/64 bit operating system.) Topic locked...
  2. The output from your sessionstart.php file doesn't match the posted code above. Are you sure what's actually in that files? Could you post the sessionstart.php file again. Are you using any foreign language characters (non ASCII) or any control/non-printing in the 'test' array index name, so that what is actually showing in your file isn't what is being shown in your posts in the forum? We have seen times where the copy/paste into the forum post produces 'clean' code that works, but there is something in the actual code file that doesn't match. Try deleting the ['test'] portion of the $_SESSION variable and retype it. When I visit your two pages, I get the same session id cookie value on both pages. That indicates that the session_start on both pages is starting/resuming the same session data, but the ['test'] index isn't present on the 2nd page. There may be an issue with the server where the file name is being created, but the actual file isn't (there is typically a php error when this type of thing occurs.)
  3. Do you have php's error_reporting set to E_ALL and display_errors set to ON so that any session related errors will be reported and displayed? You could have a session.save_path problem or a header error due to your file's character encoding containing the BOM (Byte Order Mark) characters.
  4. @cyberRobot, at the top of the page, means before you output anything to the browser - Your code worked, because php has a setting, mentioned by kicken in this thread, that hides incorrectly coded pages, but results in code that is not portable between different server configurations and should be avoided.
  5. That's not shown in the code you posted and we only see the information that you post.
  6. Nope. By injection sql with something like ' OR id=1, a hacker can make your query match any row in your table. Your query would become - SELECT * FROM users WHERE token='' OR id=1
  7. ^^^ That would imply that you are trying to put the posted code onto a web page. You cannot output anything on a web page besides the html/css/javascript. Any force-download/dynamic image must be output as a completely separate response by putting a link to the force-download .php code into your html markup on a web page. What's the actual code on the page that doesn't work? Also, how exactly did you turn on error_reporting/display_errors and did you confirm that they actually got changed by intentionally producing an error?
  8. The general fix for your logic would be to put the form processing code into a specific section of code that - tests if the form has been submitted, validates the inputs, then saves the submitted post data to session variables. Empty post data would be saved as an empty string to the corresponding session variable. In the form code for the value='...' attributes, if the corresponding session variable isset, meaning that the form has been submitted one or more times, you would use it's value, which could be an empty string, else use an empty value.
  9. Your forgot to tell us what error or symptom you saw in front of you that leads you to believe your code isn't working. Without that information, since we are not standing right next to you, it's a little hard to narrow down the dozen different things that could be wrong with any piece of code to the one or two actual things to check.
  10. This is secondary to the problem you are having, but by putting the $row_id variable directly into the query being prepared, you are allowing sql injection, not preventing it. One of the main points of using prepared query statements is to prevent sql injection. You would put a place holder into the query for the id value, then supply the actual value at the time the query is executed. Edit: ^^^ Which I had already posted at the end of your last thread - http://forums.phpfreaks.com/topic/271784-show-row/#entry1398388
  11. Topic locked to prevent replies that should be in the original thread. @jazzman1, I moved your post from this thread to the original thread.
  12. If you are getting a notification email with a problem with the link in it, please start a thread in the PHPFreaks Questions, Comments section - http://forums.phpfreaks.com/forum/23-phpfreakscom-questions-comments-suggestions/ Copy/paste the link from the notification email so that an admin can find what is wrong with it.
  13. Your thread didn't disappear, unless you mean that you couldn't find it by looking under your profile (which doesn't work as it should) - http://forums.phpfre...configphp-file/
  14. If you look at the code I posted, you will see that I modified the code in his function to use the modified data structure. In fact, the code I posted is a working example. Put it into a .php file and play with it to see what the code is doing.
  15. You should define the fields (legend text, field name, field type) in an array (or a database table), then simply loop over the list of field definitions and build the form using php code.
×
×
  • 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.