Jump to content
Larry Ullman's Book Forums

masterlayouts

Members
  • Content Count

    64
  • Joined

  • Last visited

  • Days Won

    1

masterlayouts last won the day on April 16 2012

masterlayouts had the most liked content!

Community Reputation

3 Neutral

About masterlayouts

  • Rank
    Advanced Member
  1. Hello Larry, Thank you for all your help, I learned many things reading your books and now I am back to the desk for learning after many hours of producing. You were right that a programmer may have a very nice life doing procedural programming and I have to say that I finished a quite big project and I didn't mind 'repeating myself' as in fact was not that bad, put things in functions and the repeating part was rather easy: copy/paste and changing a few things. I like the fact that I can keep things separate, HTML, SQL, PHP, CSS. Anyway... I've got so used with your way and the patterns I
  2. Does it make any sense, security wise, to have the front-end separated by back-end of an application by storing the two sets of data in different databases? Or there are other ways how to separate one from the other, as per example by setting different privileges for users who access the database? Thank you.
  3. Because we plan for it and this is the client's specifications. It is a job site, so there will be many pages with job listings, split by various criteria like country, domain...etc. Here it make sense the approach learned from your book example. People apply for jobs. The number of people that apply for a certain job it's a lot smaller... we should have less than 2-3 pages with results (as opposed to hundreds and maybe thousands). Here I was thinking to make the pagination based on the number returned by mysqli_stmt_num_rows($stmt). Both are generated on the fly, but it is a safe assumpti
  4. Thank you for your reply, I put it together and works well. I do not want to beat the death horse, but I have another question related to the issue of pagination. In the script provided we check first for a parameter p for the page, and if it's not provided we query to find out how many records do we have and split the records per page. Certainly, when we anticipate a lot of records and we do not expect (or there are not so important) changes I can certainly see the advantage of querying first for a count of the records than limit the query. Now I am thinking to two situations. First s
  5. Thank you for your answer. I have a search page and a result page. I changed the form method from POST to GET as per your advise. If the form has a text field named "keywords" and the value empty, also a submit button named "search" with the value "search database" when I click on the submit button I noticed a few things and I would like to ask a few questions about it. First I noticed that the URL contain a parameter 'submit' and its value, like following: http://localhost/results.php?keywords=&search=search+database My first question is if it's possible to eliminate the
  6. I have the following problem. On the page where I output the results of the query I also have the form (it is the same page). One of the fields is used by users for keyword searches in boolean mode (MATCH... AGAINST). Now if I click the link to the next set of results p=2&s=10 (let's say) I get an error because the content of the form is empty and even if I gave the parameters for "page" and "start" I do not pass the input for user's search/keywords (that input text field). I was thinking to put the input into a hidden field and the value of that hidden field will always be the $_POST for
  7. True, but the root of the problem is the same thing that we debate in other thread: properly sanitizing the user input. If the input is properly sanitized I do not see how anybody would benefit of a function that search for the presence of keywords such "CC" and "BCC". With the same token we should create functions that are hunting keywords to prevent SQL injection, yet we do not do that. We prefer as mechanism of defense sanitizing the user data. I would prefer not to use a function such the scrubber, but to have a high degree of certainty that the user input is properly sanitized. I
  8. I am sorry, this being a written forum and not a speaking one you must took it the wrong way. Obviously I cannot pretend to you to be clairvoyant and anticipate changes in mysql engines. In fact you received similar questions about PHP6 and my opinion was (as you can probably check) that it cause no difficulties of understanding and learning PHP. I merely made a suggestion that the forum as well as the book should reflect major changes and I believe the new innodb with fullindex feature is such a major change. My point was not to through away the book, but to pin a thread, add a downloadable p
  9. if the user input is properly sanitized from the beginning i do not see how the form may be abused. The problem is why would somebody have access to the email's header in the first place? Why would somebody be allowed to enter control characters as input in the form? If it's a contact form, than the first argument of the function mail is hidden, the second should take the subject and I will let it alphanumeric, than the body. I see no point in hunting CC and BCC... $string = "\n \r"; echo filter_var($string, FILTER_SANITIZE_SPECIAL_CHARS);
  10. Thank you for your answer. I guess we have one kind of problems with input and another kind of problems with the output. I just gave an XSS example, but the question was meant for SQL injection as well. I am happy you address them both and made the distinction clear. In my opinion, the first kind of problems does not necessary cause problems to the other and vice-versa. One can have a XSS problem if decide to output the result query and in that result figures the attacker's crafted XSS snippet, otherwise there is no problem. In this context I was asking about the queries that perform s
  11. All form input has to be sanitized and run through mysqli_real_escape mechanism. My question is do we have to sanitize the form input for that/those field/fields that will add to a query whose function is just search and that input is never displayed or otherwise used in the application? As result risky user input as the attempt of XSS or SQL injection may happen. I am interested to know if the database will take care of the input and escape it or do whatever it is necessary by itself or do I have to sanitize the input before add it to the query? $q = 'SELECT subject, body FROM messages W
  12. Should we sanitize it or the db will handle it? $q = 'SELECT subject, body FROM messages WHERE MATCH(body, subject) AGAINST('<IMG SRC="javascript:alert('XSS');">')'; Can you please put it in an working example?
  13. Hi Hartley, thank you for your reply. The thing is that the number of values is variable and doing something to generate a unique name requires the same effort. I am interested in the best practices here, otherwise I assume it may be done either way. I am also interested if having the value of the parameter of numeric value is an advantage or not. I am guessing it is easier to use numbers; on the other hand if the database has a look up table to restrict the input to predefined values and this values are string I assume it is equally safe, the advantage being that it has meaning and one don't
  14. http://www.larryullm...__fromsearch__1 I am using PHP 5.3 and I never encountered any problem with the examples in this book. Before I was using PHP 5.2 and still didn't run into any problem. From what you say you are using you should not have any issues at all.
  15. Sending values to a script (chapter 9), we are using hidden form fields and URL parameters. What if I want to pass more values for one parameter? (not "name1=value1&name2=value2", rather "name1" having "value1" and "value2"). In the hidden form element I guess we define the element's value as an array. I am more interested in the URL situation, what will work best. Is it safer to use numeric values as parameters or strings will be just fine?
×
×
  • Create New...