Jump to content

requinix

Administrators
  • Content Count

    11,547
  • Joined

  • Last visited

  • Days Won

    232

Everything posted by requinix

  1. function submit(){ global $API; if(empty($captcha) || $captcha == '' || !isset($captcha)) Variables defined outside functions are not available inside functions. They should be passed in as function arguments, like you're doing with post_content() and $query.
  2. User doesn't care. They don't look at URLs when they're just browsing around, and if they want to share the page they'll either use a share button or copy/paste what's up there. In fact that copying and pasting is a huge reason why ideas like putting session IDs into the URL (PHP's session.use_cookies/use_only_cookies) are strongly discouraged. That said, try to keep it simple. example.com/product.php?id=123 (or /products/123) is fine. Attempting to obfuscate it because you're scared, like example.com/product.php?product_id=uw433hyg5kishev6nyliser6nbyioq2gv49n68of325ob8nq534tb8, is not fine. People don't like things they can't understand: "123" is a number and people are okay with numbers, "B00005N5PF" is some sort of cryptic ID but it's okay too because it's short and easy to understand, but "uw433hyg5kishev6nyliser6nbyioq2gv49n68of325ob8nq534tb8" is a code and codes are for hackers. CoDeS aRe FoR hAcKeRs Probably, yeah. Lots of stuff on the internet already works like that. People are used to it.
  3. Implied in my reply was "you should look into why this is and deal with it accordingly". It's a symptom of a problem. If there are business needs that are changing, the problem is that the business doesn't know what it wants to do, and there needs to be more planning and thinking before rushing into development. If there are programming needs that change then... well, actually, there needs to be more planning and thinking before rushing into development for that too. That aside, in your shoes, I would regenerate the code every time. Use those files as a base and put your own implementation into, for example, traits - a thing that can be easily added into a class.
  4. Is that what you want to do? Sounds right.
  5. The PHP you showed and that WebForms-based code are completely different... How about this: what is the HTML form you need to support, and how are you going to present the results to the user?
  6. The code you posted is full of syntax errors that would prevent PHP from executing it at all.
  7. Well, I do see a number of things that are incorrect, and some things that should be done differently, but so far nothing that would prevent it from working outright. If you don't see any errors then it means you don't have PHP set up to report them correctly - or at all. Make sure you have error_reporting = -1 log_errors = on in your php.ini. Then look in your error log (according to the error_log setting, or else your web server's log) for messages. There will be some, so if you don't see any then it's not set up right.
  8. Your entities should not be changing so frequently that you feel a need to automate updating the code...
  9. Please post your actual code instead of... whatever that is.
  10. Google Sheets? A clipboard with paper and pen? Post-it notes? When I had to track my own time, I just... tracked my own time. Sounds like you need something simple. These kinds of things can be hacked together pretty quickly in PHP.
  11. If you don't care about supporting IE, there's fetch(). https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API https://caniuse.com/#feat=fetch
  12. God, I hate DataTables. I don't recognize toggle(). Where is that function coming from? Because that would be what you modify.
  13. If you need counts according to the classroom and some other columns then your query should group by the classroom and the other columns. You'll have too many rows, of course. Can't really put it into the table like that. So do some processing on the results before you try to display them. Use the classroom to build a "row", then look at the other columns to decide what should show up in each of the "columns". $classrooms = []; foreach (/* rows from the query */ as $row) { list( "ClassroomName" => $classroom, "childcaretype" => $cc, "hstype" => $hs, "cpsstatus" => $cps, "TotalChildren" => $total ) = $row; if (!isset($classrooms[$classroom])) { $classrooms[$classroom] = [ "KIDS ENROLLED" => 0, "CC Only" => 0, "EHS/PI" => 0, "CC/PI" => 0, ... ] } $classrooms[$classroom]["KIDS ENROLLED"] += $total; /* update other columns... */ } ksort($classrooms); // sort by name That's the basic idea: total up the values as you go through all the rows. Then your table displays what's in $classrooms.
  14. Yeah, probably. I didn't really think too hard about what was in the table. Point is, the row corresponds to one person's survey results. Depends on the database. PostgreSQL goes like ...WHERE result->'answers'->>'23' = 'Blue' References? No. I think your issue is just wrapping your head around what it is and how it works. You can kinda think of the arrow chain above as a "column", in that it will get you a value from the JSON. If you wanted to query the table for results between a date range, it might be like ...WHERE result->'answers'->>'123' BETWEEN '2019-01-02 03:04:05' AND '2019-06-07 08:09:10' AND result->'answers'->>'456' = 789 - 'answers' is the tree structure in the JSON with the answers - '123' is the ID of the date question, whose answers are dates - the two dates are strings; your application knows (1) the question #123 is a date type so (2) it knows to build the BETWEEN...AND part of the query - '456' is the ID of the location question, whose answers are IDs corresponding to a list in some table somewhere of possible answers to choose from - 789 is the ID of the answer (location) to search for The code looks like $where = $placeholders = []; foreach ($things_to_search_for as $question_id => $search) { $question_info = get_question_info($question_id); if ($question_info["type"] == "date") { if ($search["type"] == "range") { $where[] = "result->'answers'->> ? BETWEEN ? AND ?"; $placeholders[] = $question_id; $placeholders[] = $search["start"]; $placeholders[] = $search["end"]; } } else if ($question_info["type"] == "choose") { $where[] = "result->'answers'->> ? = ?"; $placeholders[] = $question_id; $placeholders[] = $search["id"]; } } $query = $db->prepare("SELECT * FROM results_table WHERE " . implode(" AND ", $where)); $query->execute($placeholders); (If you're wondering, -> and ->> are actually operators, which means they can use placeholders) For the normalized one, I'm not sure what you're asking about. It seemed like you had it: one query to find the result IDs where the answer to a particular question fits particular criteria, and another to find all the answers for each result. The answers table would probably have multiple columns for the generic types necessary (integer, string, date/time, maybe one or two more) and you piece together the WHERE conditions much like above.
  15. You can go the relational/SQL way or the document/NoSQL way. The SQL way is the first version where you normalize everything. Definitely do not have tables with columns according to the question: it sounds nice with your hardcoded example query, but when it comes time for something dynamic you'll have to pick the column names dynamically and that's a sign of Bad Stuff. Yeah, the full query looks worse, but any good database system will be able to handle that very easily. The NoSQL way is to store each result in something like JSON form. It's still indexable, and the query to search is a little less complicated than the relational one, but it's... well, it's not relational. question_id | result ------------+------------------ 4 | { | "answers": { | "22": true, | "23": "Blue", | "24": 2, | "25": "Capricorn" | } | } (that's a hybrid relational/document style, like MySQL or PostgreSQL with JSON columns; true NoSQL doesn't have table columns and the data would be more like { "question_id": 4, "result": { ... } }) Relational works better when you need to set individual values as you go, since with a document the whole thing needs to be rewritten if some part of it changes. The downside is you have to normalize it pretty hard to get a usable schema. But then with documents, your application has to be really sure it's writing data in the proper structure because it's all essentially free-form.
  16. No, it's from HTML 4. People just didn't really start learning about it until HTML 5 and the push towards semantic markup and better web design. Any additional risks. Besides a developer having a faulty assumption of "well it's hidden from the user so they can't do anything to it". "I know it's wrong but we'll do it right next time"... yeah, if I had a nickel every time someone said that to me...
  17. Doesn't seem that way to me. Why? You don't need to do that. Managing one form would be simpler than managing three, right? <button>s support a name and value, as well as a separate (HTML) caption displayed to the user. Compare that to regular <input type=button>s which support a name and (string) value, however the value is also used as the caption. Other than the general design of what you're doing? Not especially. Hidden inputs are for when you want to include data in the form but the user isn't supposed to interact with it. It is no more or less secure than any other form field. You still have to validate it in your script like you would everything else.
  18. Confirm that the <form> is method=POST, and that your browser is POSTing data to the script (using its developer console). And that there isn't somehow a redirect happening.
  19. No. If you're not getting the output you want, and your script is responsible for creating that output, then you should be modifying your script to produce what you want. Not trying to clean up after the fact.
  20. By itself no. It helps to conceals the fact that you're using PHP, but (a) most attackers could find out quickly even if the extension was hidden, and (b) the actual security risk is in the code, not the language it's written in. "Security through obscurity" is the term, and it's not good. Besides the aesthetic reason, which IMO is actually the strongest reason, removing the extension means that your URLs are not strictly tied to the scripts supporting the page. If you had /subscribe/view-offers.php as a file then that's one thing, but maybe you move to a framework and now there's some fancy routing happening automatically and you have to tell it "/subscribe/view-offers.php" is the URL and it maps to (eg) the Subscribe controller (class) and its ViewOffers action (method). Or less likely is that you switch to .NET or Ruby or some other language. Either way, the .php extension becomes a nuisance.
  21. So does that mean what I said has helped you fix, or at least find, the source of the problem?
  22. Hmm. Doesn't sound like what you were describing in your first post. If the pattern is something-something-username, and the username doesn't itself contain hyphens, then you need to find the portion of the string after the last hyphen.
  23. Your second post in this thread was "here's some code that does a hash and it looks fine to me". Sure, you can be more secure: use even stronger hashes, even higher computation costs, even longer salts... But where do you stop?
  24. Credit card data is a whole 'nother ball of wax. If you're storing it in any form and you don't already know about PCI compliance then stop storing it and learn about that. If you do the hash right. And since that's a hard target to hit, use password_hash(). Not when you know that the input is 15-16 characters long and consists only of digits. [edit] And one of those digits is a checksum so the real input is actually 14-15 digits. [edit 2] And credit card numbers all start with one of a fixed set of prefix digits...
  25. Kinda, yeah. But changing your oil and cryptography are very different things. Your users are trusting you with sensitive information like their email address and password. If I needed my car to bring me cross-country and I had to bring my spouse and children with me, I wouldn't change my own oil. It's fine that I know how to do it, and for simple situations I would, but when it really matters I will set aside my own desires and trust the people who really know what they're doing. [edit] Cryptography is the same in that respect, but it has a much higher bar to meet in order to be even somewhat good at it. "Rolling your own" version could go well and you could get it right, or you could do it poorly and compromise the integrity of the hash. What basic programmer education will teach you about passwords is enough so that you don't do it so terribly that the false sense of security of having "hashing" obscures the actual insecurity of what was designed.
×
×
  • 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.