Jump to content

scootstah

Staff Alumni
  • Posts

    3,858
  • Joined

  • Last visited

  • Days Won

    29

Everything posted by scootstah

  1. It's possible someone hit refresh on their browser and resent the form.
  2. I always use arrays when using data from a database. A lot of the array functions don't work on objects, so if you want to use them you'll have to at some point convert the object to an array - which is just a waste of time when you could have used arrays to start with.
  3. For a website like that, it is probably more beneficial to use an existing platform. It doesn't have to be a framework though, you could use a CMS like Drupal. Using existing platforms means that all of the boring redundant code is already there, and you can focus on exciting features for the application. Otherwise, you are going to spend a large amount of time building things like: DB wrappers, user authentication, URI routing, email libraries, etc etc. All of these things already exist in every framework and CMS.
  4. It is not an error, you are echo'ing $query which is a resource. If you want to know more about the resource you can use var_dump.
  5. Hahah, nice!
  6. Happy birthday!
  7. Says the guy with database access. Who would know?
  8. Yeah. The standard way is to not do that. What's wrong with a login form?
  9. Well, that game is ruined.
  10. GNU Am I doing it right?
  11. Normally I would agree, but in her example the user has to manually click "login" and is not redirected there. They are redirected to an error page.
  12. Most people like to keep user data as close to its original form as possible. Store it the way the user enters it, and then modify it as needed only when you need to. The only time you need to sanitize for XSS is when outputting the data as HTML. There are tons more ways to use data that don't require it to be sanitized for XSS. Ultimately, it is your decision whether you sanitize on input or output. It will work either way, but if you sanitize on input then you are only creating more work for yourself.
  13. Sessions is usually how you pass data between scripts. Why wouldn't you? Treat it as a new request.
  14. There are ways to automatically cleanse the data on output so that you don't have to explicitly do it all over the place. For example, if you use templating then you can cleanse any variable data sent to the template.
  15. $array = array('pear', 'apple', 'banana'); foreach($array as $a) { echo '<input type="checkbox" name="fruit[' . $a . ']" value="1" /> ' . $a . '<br />'; }
  16. By doing that you are potentially limiting what you can do with the data, because you have mangled it. It's usually preferred to maintain data integrity and only adjust it when it's needed. For example there might be a format where you literally want a < instead of <. Sure you could just reverse the process, but you can't be sure that the data will be exactly as it was.
  17. Yes, prepared statements prevent SQL injection when you bind parameters.
  18. Yes! How many more times must we tell you that before it penetrates? Using SELECT * when you are not using the data from all of the columns is less efficient and a waste of resources.
  19. Most frameworks have libraries for user auth as well.
  20. I lease my own dedicated servers. www.kimsufi.ie Wow, those seem really cheap for dedicated servers.
  21. foreach
  22. If you want to do validation without pressing the submit button first, you'll need to use Javascript.
  23. This is the setReport function: function setReport(url) { var element = document.getElementById("rpt_result"); //???????? if (!element) { alert(id + "not found."); return; } var req = AJAXRequest(); if (req != null) { req.onreadystatechange = processRequest;//??request?onReadyStateChange?? //url = url+"?timestamp="+(new Date().getTime());//?????????url???,??cache if (url.indexOf('http')>=0){ url = "/php/result.php?url="+url; }else{ var urlPath = document.URL.substring(0,document.URL.lastIndexOf('/')+1); url = "/php/result.php?url="+urlPath+url; } req.open('GET', url, false); req.send(null); } else { element.innerHTML = ""; return; } //??request?onReadyStateChange?? function processRequest () { if (req.readyState == 4) {// readyState = 4 ????server????????? if (req.status == 200 || req.status == 0) {// status = 200 ??server????(HTTP code) element.innerHTML = req.responseText; }else{ element.innerHTML = "????"; } } } } I just examined the post data being sent and it looks like all you need to do is spoof the AJAX request. Try something like: $ch = curl_init(); $post = array('ajax' => 'true', 'input_stock_code' => 'your value here'); curl_setopt($ch, CURLOPT_URL, 'http://www.gretai.org.tw/ch/stock/statistics/monthly/st42.php'); curl_setopt($ch, CURLOPT_POST, count($post)); curl_setopt($ch, CURLOPT_POSTFIELDS, $post); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $result = curl_exec($ch); curl_close($ch);
  24. Sorry, but I think you are the minority here. If you're happy with GoDaddy, that's fine - I'm glad they treat you well. But, I know many people that share my feelings and I will avoid them like the plague for web hosting. I have AT&T too. When my girlfriend and I got setup with our family plan, they literally screwed it up in every way possible. We did it online which meant the activation fee was supposed to be waived. We signed up for like a 500 minute/month family plan with unlimited texting and two smartphones with 200MB/month data plan (the cheapest, we're usually on WiFi anyway). This is what they did: - Did not waive the activation fee on either phone (so $80 total added to the bill) - Made TWO family plans for each line, instead of both lines under one family plan - No unlimited texting on one phone - Bumped both data plans up to the most expensive one It took me probably 2-3 hours on the customer support line to get everything fixed. The guy on the phone told me that some of these problems were "common", and most people don't even notice. Are you kidding me?! How much more incompetent can you be? I haven't had any other problems with them since that, though. The service is kind of shitty in my area but that's not really their fault.
  25. Yes, it makes a big difference. Let me illustrate. Suppose you have the columns: pants, shirt, shoes, socks, and hat. If you use an asterisk, the result set will look something like: array ( 0 => array( 'pants' => 'jeans', 'shirt' => 't-shirt', 'shoes' => 'sneakers', 'socks' => 'ankle', 'hat' => 'cap' ), 1 => array( 'pants' => 'shorts', 'shirt' => 'tanktop', 'shoes' => 'sandles', 'socks' => '', 'hat' => 'viser' ), 2 => array( 'pants' => 'suit', 'shirt' => 'polo', 'shoes' => 'dress', 'socks' => 'fancy', 'hat' => '' ) ) But, if you only plan on using the "pants" data, and you do SELECT pants FROM ... then your result set will look like: array ( 0 => array( 'pants' => 'jeans', ), 1 => array( 'pants' => 'shorts', ), 2 => array( 'pants' => 'suit', ) ) So even if you only use the "pants" data, the entire result set is loaded into memory and thrown around in loops. With that said, I think your database design is a bit flawed if you have every article of clothing as columns. The articles of clothing should be "categories" in their own table.
×
×
  • 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.