Jump to content

Jacques1

Members
  • Posts

    4,207
  • Joined

  • Last visited

  • Days Won

    209

Everything posted by Jacques1

  1. The code you've posted isn't even syntactically valid, so that's certainly not what you're using to download the images. That's not very clever, because the link code is the relevant part here. The cURL code itself is valid (except for the syntax problems and lack of error handling) and downloads the right image when used with the above URL.
  2. The requirements obviously depend on the specific job. In some projects, there's a strict separation of backend programming (PHP, SQL etc.) and the frontend (HTML, CSS, JavaScript). In other cases, programmers are expected to do pretty much everything. In general, you should at least have basic knowledge and be able to create a simple page from scratch. If you don't know anything about HTML, that can be a problem in job interviews.
  3. First off, the point of prepared statements and escaping is to separate the data from the surrounding language context and prevent syntax conflicts. If you don't know what that means, try to insert "O'Reilly" into a single-quoted SQL string. This has nothing to do with "attacks". It's not an "attack" to be named O'Reilly. The problem here is a software defect caused by naive programming. Of course prepared statements can also prevent attacks. But the primary goal is code correctness -- the fact that correct software happens to be more robust against attacks is a nice side effect. Secondly, assuming that values from the database are somehow inherently secure is wrong and can leave your application wide open to second-order injections. You shouldn't make any assumptions about whether or not a value is "secure". a) you're missing the point (see above), b) your assessment may very well be wrong (attackers often have a lot more fantasy than the average PHP programmer) and c) constantly switching between escaped and unescaped values will sooner or later lead to a mistake. The correct approach is to always use parameters, unless the string is explicitly supposed to contain an SQL fragment. This is true for every language, not just SQL. It's the same with HTML, XML, shell commands etc. Your learning theories are bullshit. The truth is that you haven't made any significant progress. Several very knowledgeable users have spent a lot of time explaining the same basics over and over again, and they've been exceptionally patient and friendly. None of this has helped. You've either simply ignored them or come up with all kinds of reasons for why their advice isn't relevant. So how about you stop blaming everybody else and realize that the problem is you. PHP isn't rocket science. Somebody who already has prior programming experience can definitely learn to write decent code in a few weeks. However, learning requires motivation and the willingness to shut up and listen. You don't have that. Whenever somebody points out a mistake, you make it anyway. Whenever you get important information, you brush it off, assuming that you somehow know better. With that attitude, you may be able to produce code. But you won't learn how to program.
  4. If you want help with code, then we need to actually see that code. None of us can read your mind. Generally speaking, the recommended approach is to use cURL and generate the URL query string with http_build_query().
  5. Your form uses the view script as an image source, and image sources have to be public by definition. That's why you're getting a 404 error as soon as you remove the script. Again: The whole point of the view script is to be public and give access to the images. That's the only reason why it exists. Trying to hide it makes absolutely no sense.
  6. If you move the script outside of the document root, then how is any client supposed to access it? The whole point of the access script is that it's in fact publicly accessible.
  7. He has been told that at least 10 times. Literally. I think the current consensus is that he cannot learn.
  8. Google. It's an abandoned, buggy, useless HTML library which, for some strange reason, has gained popularity among newbies. The solution is simple: Throw away the library and switch to one of the PHP HTML extensions like DOM. You can use XPath to search for elements. Turn your error reporting all the way up and either log the errors (in production) or display them on the screen (during development). Read the manual and learn to handle errors. When a function may return false in case of an error, you need to actually cover that case.
  9. Did you even read the original post? The OP is ordering the graphics by dimension. The specifcations are absolutely clear. What the OP wants makes perfect sense, and I see no reason whatsoever for claiming ambiguity when there is none and inventing features nobody asked for. Even if she somehow changed her mind and wanted a different ordering scheme, you would still only run one query. Not nested queries within nested queries within nested queries. What you're proposing is insanely inefficient, bloats the code beyond any reasonable limit and is even more complicated than what the OP currently has. I'm all for new ideas, and I wouldn't even have commented on your approach if I thought it was OK. It's quite common that a thread ends with multiple valid solutions. But when the proposed solution is worse than the code which came in, there's definitely something wrong.
  10. When your suggestion doesn't make sense, then it's pretty much my job to disagree with you. The specs are absolutely clear, and once again, this is a very, very simple task. There's no point in turning this into advanced SQL gymnastics when the OP already struggles with a single query.
  11. Like what? Locking the entire file exclusively for an indefinite amount of time as soon as any process reads it? Using optimistic locks where the queries can constantly fail? Since you also want to allow manual edits, you have an even bigger problem, because file operations outside of your interface completely ignore your locks. In other words: You have no idea who is writing what when. Like what? For the use case you're describing, SQLite is vastly superior in every aspect. Flat files can be useful for something like configurations. But then I either want no library at all or just a few lines of code which correctly handle updates and don't corrupt my data.
  12. Your GROUP BY doesn't make any sense in this context (apparently you confuse this with something else like SELECT DISCTINCT), and multiple nested queries are going to be extremely inefficient and make the code much more complex than necessary. This is a simple task with a simple solution.
  13. The library has fundamental design problems and is subject to both race conditions and data corruption. For example, if two processes or threads read() the same file, increment a counter within the data and then write() their results, the second update overwrites the first one, and the counter is only incremented once. There's not even an error to indicate that something went wrong, the update is simply gone. Now imagine a real application which has to do far more complex updates all the time. When that's just a matter of luck, the user has a problem. In addition to that, the write() operation itself doesn't even attempt to keep the files intact. It first truncates them and then starts to write the new content. If anything goes wrong now, the user is left with an empty or partially written file. And of course the performance of constantly reading, decoding, sifting through, re-encoding and writing entire files is abysmal. So, no, this is not a “MySQL alternative”, and you shouldn't market it as such. Realistically, this is an experimal library for small, unimporant files. Personally, I never quite understood the hype around “flat-file databases”, given that a) even the cheapest hoster has some kind of SQL database now and b) there's SQLite for embedded databases – but that's another story.
  14. So, do you want help or not? If the task isn't really important, I'm OK with that. I have more than enough to do, so we can just forget about the thread and move on. If you do want a solution, then I expect you to turn your brain on and actively work on the problem. You have no idea what I'm talking about? That's strange, because this is your task. I didn't come up with it. You did. Your initial approach is horrendeously complex, because you're trying to render the result set directly, and that forces you to have all those if checks. I'm proposing a simplification: First turn the result set into a more convient data structure. Then render that new data structure. No if statements, no $current_* variables. Just a loop. Which part of this do you not understand?
  15. Turn your brain on, dude. You cannot use the same URL pattern for categories and posts. It's not possible. No SEO expert can do it. Not even Chuck Norris can do it. It's nonsensical. Let's say I had this URL: https://mysite.com/paris Tell me: Is that a category or a post? You don't know, right? Well, then how on earth is Apache supposed to know? Apache has to be able to distinguish between categories and posts. You need two different URL patterns. For example, posts could be subresources of categories: https://yoursite.com/some-category/some-post Or you could have two entirely separate paths: https://yoursite.com/categories/some-category https://yoursite.com/posts/some-post Whatever you do, the URLs of categories and paths must be distinguishable.
  16. My point is: The form shouldn't contain the username at all. The session alone tells you who the user is. Carrying the username around is not only superfluous, it's absolutely wrong, because the user may willingly or accidently change that field and break your lookup system. What if I enter the name of somebody else? Does that allow me to forge reviews? What if I enter a nonsense name? The whole session approach doesn't make much sense. If you have a log-in system with an underlying database, then the session shouldn't contain anything but the user ID. That's how you reference the user. Names, e-mail addresses etc. should stay in the database. Besides that, you definitely need to work on your HTML. Escape PHP variables before you insert them. Avoid this inline CSS mess and write clean semantic markup. I'm glad to hear that you've scrapped the previous code, but there's still a lot to learn. Just because the code seemingly "works" doesn't mean it's actually valid.
  17. If you want a pat on the back rather than technical advice, don't come to a programming forum.
  18. You'll make your life a lot easier if you first turn the result set into a more convenient format and then render that custom format. For example: [ '100x100' => [ 'bob@example.com' => [ $bob_donation_1, $bob_donation_2, // ... ], 'sue@example.com' => [ $sue_donation_1, $sue_donation_2, // ... ] ], '150x200' => [ // ... ], ] This can be rendered with a simple nested foreach loop rather than a complex state machine. Pre-processing the result set is also trivial. donations = [] for each row in result_set: donations[row["width"] + "x" + row["height"]]["email"][] = all_donation_related_data_you_need
  19. Looks like you're writing your code with a completely inappropriate tool (Microsoft Word?) which replaces straight quotes with typographic quotes: " -> ” HTML parsers have no idea what to do with those. Use a proper code editor or an IDE.
  20. My answer had two sentences. Two. When you don't even bother to read two sentences and instead repeat the question as if I was an idiot, then, yes, I'll be less patient than I was the first time. If this was a complex problem with a long answer which cannot be processed in one go, I could see how you might miss some information. But not reading two sentences to me is a sign of disrespect.
  21. No shit. How about you read the friggin' replies? Let me try again: You need to do an integer division. Integer division. That means cutting off the fractional part. Like you did in elementary school. 30/60 is 0.5. But intdiv(30, 60) is 0. Because 30 = 0 × 60 + 30.
  22. That's because the code makes no sense, just like all the other code in this thread. You seem to have no idea what the code you're writing down even means – which is pretty surprising for somebody with 10 years of experience. Programming doesn't work like this. Before you write code, you need an actual understanding of the problem and a solution. So you claim that the library (this one?) doesn't support multiple lines. But the README explicitly says that it does, and there's code to handle lines. Have you verified your assumption? Have you tried different variations like a bigger box or smaller text? Because it would be fairly stupid to look for a solution when the problem doesn't even exist.
  23. The real problem is that you're jumping to advanced tasks before you've fully understood the basics, and you start writing code before you've finished the concept. Learn the PHP basics first. Learn how to safely query the database with PDO and prepared statements. Learn the basics of security like HTML-escaping and password hashing. And most importantly: Actually think about what you're doing, don't just blindly copy and paste code you've found somewhere on the Internet. Does it really make sense to print internal error message on the website? Attackers will surely find this information useful, but legitimate users cannot do anything with it and will probably wonder what the hell is going on. Does it really make sense to repeatedly fetch rows with a loop when you know there's exactly one row? Start small and build your application from the ground up. Simply copying and pasting code fragments may yield quick results at first, but what's the point of all that code when most of it is garbage and you have no idea what it even does? Secondly, make a plan before you start typing. You don't need walls of diagrams, but you should at least have a basic idea of where this is going. Trial and error doesn't work. Why do you even want to insert the username into a form field? Do you want the user to change it and submit the review under a different name? What's the point of that?
×
×
  • 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.