gizmola

Yeah, this seems to be a prefix towards an attempt to mass generate registrations for free gifts from this site. Locking it.

Also, this thread is probably interesting to consider....

I'm all for academic exercises for the benefit of learning. I think you will find this page of some help in continuing to explore the jpeg and jfif standards. However if your goal is simply to verify if an image is valid or not, that is problematic, because jfif allows for sections of a file to be ignored, so that special data could be placed there when the file is created. You could look at exif as essentially being this type of extension, so using the exif check functions is valuable in combination with other techniques. Exif data doesn't have to be there, but if you decide that you will only accept images that also have exif, then that is another valuable and efficient check, as you can use an exif checking function to exclude images that don't have valid exif data. In general, the proven method of knocking down malicious images is to use a combination of getimagesize and imagecreatefromstring, or the imagemagick routines kicken referenced. You used getimagesize to knock down files you have already decided are too large, and then recreate the image from file data. Either of these failing should cause rejection. Trying to go through the files and decipher them is most certainly a block operation where you would want to read the binary values, looking for the segments, and have routines that can decipher those individual segments. A simple loop is not going to be maintainable in my opinion. If I was trying to do this, I'd also want to try and see what gd and/or imagemagick source is doing, as those are both open source libraries written in c/c++. For example, imagemagick has a component used to identify the internals of an image. It's available in their command line tool that allows analysis and modification of an image. The source is here. A very large and complicated bit of code it seems.

In regards to prior code, while you should in general never interpolate variables directly into a sql statement and use prepared statements, in this case it doesn't matter because you are running md5 on both parameters, and it doesn't matter if someone tries to sql inject data, as the md5 function will convert the input and output an md5 string. This is one of very few cases where it doesn't matter what the input is. I'm not sure other than for testing why you are selecting the userkey. It's fine to have it in the criteria, but you wouldn't want or need that value to be returned in the result set.

Is this a new problem? I'm not sure what you are trying to debug here. You didn't use password_hash() to make the encrypted password so you don't need to use password_verify() to check it. You stated that you used md5() to encrypt the passwords. I'm not going to go into why md5 (especially without a salt) is not recommended, because that decision was made by someone in the past, and it is what it is. Your query is already checking for a name AND password match. Perhaps that was what you had previously (or something similar). I'm not sure why you thought that needed to be changed for php7. Even if there are things that weren't recommended security practices, you can't "upgrade" a security scheme by changing a few functions. In your case, all you need do is something like: function LogMeX2($name, $pwd1) { $sql = "SELECT User, UserKey FROM LIBusersX WHERE UserKey = '" . md5($pwd1) . "' AND UserN = '" . md5($name) . "'"; $pdo = connectDB(); $stmt = $pdo->prepare($sql); $stmt->execute(); if(!$row = $stmt->fetch()) { return false; } // username and password matched, return user id return $row['User']; }

You have to figure out where $pdo is being assigned. There must be some include or required where the database connection is initialized. Clearly there is already a $pdo variable being passed to that function.

Yes it is end of life. Obviously they are behind because PHP 5.6 (which was the last release in the PHP 5 branch) was end of life over 4 years ago. There was no PHP 6.

Aside from the interesting comments made by kicken and maxxd, it's hard to help you with a database problem when you provided us with no actual code that read from your database. I have a lot of questions, but it goes without saying that, if your css file is being generated dynamically with database variables interpolated, changing something in the database doesn't automagically cause the generated css file to change, nor will it make the source page reload, nor will it clear the browser cache of the css file. By default stylesheets will be cached, so it's common to have to use some sort of cache busting scheme to get around this behavior. For example, lets' asssume your script is named style.php. You might need the main html page to add a url parameter like: <link rel="stylesheet" href="style.php?v=something"> You could do something like generate a random string for the parameter like this: <link rel="stylesheet" href="style.php?v=<?= bin2hex(random_bytes(8)) ?>"> This would essentially defeat any caching of the css file, but also -- you get no css caching I'm not sure what your actual issue is, but this might be related to whatever you are experiencing, although you also may have database query and fetch issues we don't know about.

The point of the exit is, consider this pseudo code Do thing 1 Do thing 2 exit Do thing 3 Do thing 4 So with an exit, there is no way for execution to get to thing 3 and thing 4. The key thing that might help you understand, is where code is executing. This is difficult sometimes even for developers who are actually working in web development as kicken's story illustrates. In your case, "Do thing 2" is actually: set a browser header to tell the browser/client to redirect to a new html page. This is the way the HTTP protocol works. The user/client's browser makes a request, and the server sends a response. These request/response chains happen as rapidly as possible, and the underlying network connections are opened and closed as soon as the request and response are completed. The problem here, and the reason you NEED an exit, is because, it is entirely up to the browser to perform the redirect and reload. In other words, sending the redirect header in a response is the server "trusting" the client to do the right thing. So when you say it works, that is because in a typical scenario, the browser does make the redirect as requested. One of the many difficulties in web development is that the client can "never be trusted" to do what it is supposed to do. There are all sorts of methods and tools that people can use to emulate an HTTP client. In fact, serverside code will often emulate a client for the purposes of doing things like talking to API services or electronic payment gateways. People often also mistakenly think if they add javascript (which runs in the client browser) security and validation routines, then this secures a page, when in fact, these same tools can run pages without running javascript, and thus bypassing the javascript validation and security. Again, the rule of thumb is "client data can not be trusted". This is also the same area where SQL injection bugs catch people: because they accepted client data, and trusted that it was appropriate without validating it first. So to summarize, you won't see something different with an exit, because the client does its redirect as expected. However, without the exit, the script continues to run on the server until it completes. At best that's just some wasted execution time, but at worst it could be entry into entire sections of code you didn't expect it to. If you have a logging/debugging feature in your code, where you could log out messages, you could put a logging line directly after the redirect and you would see that it would log out a message, even though the header() function runs, and the client accepts that and redirects. One amazing tool that everyone has available to them, is the developer tools built into most of the major browsers. All of them have a network tab. Getting familiar with that tab is a huge help in understand how HTTP works and how your code works. Here's a screen shot of the developer tool window in chrome, open to the yahoo.com homepage. I've clicked on the main get request, showing what my browser sent as a request. From here I can look at the response, as well as all the subsequent requests that came from my browser once the html was delivered from the server. This is because all the individual components of the page (css, javascript, images, videos) are loaded separately from the html that references them. This excludes js and css that were embedded in the page, but rarely do people do that, and typically are making references to load those resources. This is an amazing tool that anyone who is doing any sort of development should use regularly during development. You can see here, the important HTTP elements: Request/Method (Get,Post, etc), status code. The server and port that the request was sent to. You also can see response headers here from the server. You could check the Cookies tab to see the cookies sent by the server, and the response data in the response tab, to see what the server sent in response. Once you get a real understanding of how the web actually works via HTTP, many things become clear.

@ginerjm: Why? You are storing either a date or datetime in a database, right? If that is the case, then your extract certainly doesn't need to depend on a redundant database column, when your extract can just compute that during the process to send the data to the client. Perhaps we are also missing content on your environment. Right way: Server uses UTC Database uses UTC Always store datetime values as UTC Queries/display take into account client/enduser locale when presented. Yet it is not unusual to see people say: well I'm in albany, NY, so let me set up the system with the database to be based on the EST timezone, and then all the dates/datetimes will be what i want to see (in my local timezone). Unfortunately that creates a mess of potential confusion, and is not best practice, but if that's your reality, perhaps that is part of the underlying issue.

It's great to get some context on your problem, but then you follow that up with a page of markup. So let's be clear about the database. If you have a bunch of tables that aren't relevant to this feature, that's not at issue. What I asked for is the tables that are relevant. The tables that effect login, and membership level and this "sale visibility flag" or whatever it is that you are trying to do here. What you provided previously is useless without context. id salecheck (varchar) This is a useless table, which can't possibly be useful, unless there is something else you haven't explained. If these are just columns in a user table, then I can tell you the structure of this feature is wrong, and will never be useful, but so far we haven't gotten to that point yet. I've been developing systems for a living for decades, for companies large and small in the entertainment, gaming and telcom industries, as well as a number of consumer startups. I tell you that your problem is likely in/related to the database structure (or lack thereof) and you say: Database is fine. I say: don't use a varchar to store a boolean, and you say that is too much trouble to change, when the fact is, not only is it not too much trouble, but could have been done and taken into account within 10 minutes tops. You say: I need a default value, so I don't have to set it, after I already stated, a flag should be a tinyint with default of 0 (ie. false). Of course it's not even clear now that a flag is what you need here, since it's not clear what the use case is. The difference between us, is that I have designed databases used in systems that served 100's of millions of people, and you haven't. This is not hyperbole, as I designed the underlying database used by one of the most successful multiplayer games ever, and that served 10's of millions of players and an untold number of games at this point. When we have people with problems like yours telling us how to help you, that never ends well. We've been helping people for over 20 years, so we know a thing or two about it. Just because you have an irrational fear of changing things in the database design, isn't going to change the fact that doing so, when you know what you are doing, as most of the developers who visit this site and help people do, it is not only not dangerous or problematic, but it is also much better than trying to add spaghetti code to work around the problem. We know what is hard or dangerous. When you describe your system, which as I understand it has: Members Levels of membership Companies Company Promotions And you have a feature where you want to be able to have company promotions/sales that are shown to members of a certain membership level, that is not a difficult design problem. It's a variation of what every site that offers affiliate links does (although very few have reason to secure this away from people.) If there is a wrinkle to this that isn't clear here, you'll have to forgive me, because this has been a process of peeling the onion, in order for us to get at what that problem actually is. You want to fix it, we want to help you, but you have to be willing to meet us halfway.

I assume you have a database behind this. How have you solved it with database design? Typically this would be "subtyping". So polymorphism is not involved. What is involved would be inheritance. But I'd start with your assumption here. You basically have a list of "Finished Goods". All of them have dimensions and weight. Is this academic, because your original supposition is arbitrary and incorrect? Rather, it seems that you want to associate one or more product categories or tags to the finished goods in this list. Let's assume you had a product_type table that included a primary key and a name. That table would have in it: 'Book', 'DVD', and 'Furniture' and likely many more. You'd classify the product by having a foreign key for this table in the product table. Now beyond this, there could be any of a million different facts that relate to a product. How do you think an ERP or Amazon solves this problem? Do you think they formulate a bunch of structure specifically for each type before it can be sold? One answer is: use properties. In the database consider how you might allow for One-to-many properties such that they could be assigned to a product. When you need something generic and extensible, you often have to design something generic and extensible. Another answer is to use a structure that is intrinsically hierarchical, like json, and allow each product to store data in json format. This can then alleviate the problem with the rigidity of relational databases, in cases where you might need some data that isn't always required, and also isn't always structured exactly the same way. Some databases have json types, and then there are "Document" databases like Mongodb, which is built upon a version of json, and essentially uses json as its internal structure. From document to document in a Mongodb collection, the json structure can vary. So you could have a basic structure, and then a section that completely varies by product type.

Systems backed by a relational database are very often overlooked when people are inexperienced, and suprisingly, they are often overlooked by experienced developers as well. The reality is that the future of the system is tied to the decisions made when the database is first being designed. I like to use the analogy of saying: "people don't go and try and build a skyscraper on the foundation that laid for a one room mud hut" and yet that is what so often what happens. I would suggest we take a step back from what you perceive as your problem and take a look at your database. Proper database design takes a fraction of the time that it takes to write the code that will use that design, and yet, it is so often the case that developers are in a hurry to implement something quickly that they don't take any time to design the database properly, arguing that it can be refactored later (which it never is). What database engine are you using? I think it's mysql but I'm not sure What tables do you have What is the structure of these tables With an understanding of that, we can probably help you fix any mistakes you made, and converse effectively about how and what you might need to add. This will then lead to a better understanding of a specific functional problem you might be having.

Did you look at the code I posted? You also have a database involved apparently and yet there is no code you've shown that does anything with the database. If you're reading data from the database somewhere we don't know what that code looks like. It won't magically create session variables. Dont design something like "salecheck" in a database as a varchar(255) if all you want is a true/false yes/no. Assuming this is mysql, then use a tinyint defaulting to 0. Then when you want that to indicate true, you set it to 1.

In regards to your membership levels, that is something that also ought to have a function or class. Then for a page you could configure it at the top with something like: require_once('security_functions.php'); checkLogin(); checkSecurityLevel(); // If gets to here then they were logged in // And they were of a membership level allowing them to see the page In short, avoid writing spaghetti by breaking down individual things into functions or class methods. This will be DRY, and easier to understand, debug and maintain.

So this code redirects to nosale.php if the person has a session id and $_SESSION['salecheck'] === 'yes'. It seems you want the opposite. A couple of things: Login is login. You shouldn't have a situation where you check login state AND something else like this for a business rule. You should have generic "always run" code that checks for login state, and redirects them to the login page (for any pages that are meant to be secured. Typically you would put that code into a function or class, and include the function or class. Then you can have at the top of any secured page something like: <?php require_once('security_functions.php'); checkLogin(); // If gets to here then they were logged in // Do page specific things if (!$_SESSION['salecheck'] === true) { header("location: nosale.php"); exit; } Use PHP booleans in your session rather than a string. Nobody sees the session variables, other than your code. //Somewhere in your code $_SESSION['salecheck'] = true;

Now worries. Great to hear the community was helpful.

It looks bad. It's the equivalent of someone having a calculation where they are adding 2+3 and getting 4, and deciding to "fix" that by adding 1 to it. Your examples all seem contrived and it's still not clear to me reading this thread, what the "why" is here, because you are manipulating, copying and re-creating variables in various ways, and yet you stated earlier all you care about is getting a "day". I'm not sure what that means. UTC exists for a reason. Locale conversions exist for a reason. I've had this conversation with other people in the past who seem to have the same complaint about this, but in general, it's a simple concept: your 2/25 is not necessarily my 2/25 depending on the timezone we live in. For that reason people synchronize their servers to UTC time zone, and store dates in utc. The built ins at the OS level across the board are based on UTC. It seems like you are choosing to ignore what both Barand and Kicken have been trying to teach you. Figure out if you have a UTC or a "locale specific (ie. your timezone)" datetime. If it's UTC, and you are making a copy, but you want that copy to be locale specific, make sure you are keeping that in mind.

I made an app that uses DBAL to do this, as a quick and dirty proof of concept. Anyone with an interest can check it out here: row cloner Took less than a day start to finish, including learning enough about Bulma to get a decent looking UI put together.

You really want to focus on the ones that are programmatic. This is why using a template system like twig or even (back in the old days) smarty is so valuable. Typically this is because you have some sort of database structure where you are entering and configuring attributes related to a page. The title tag is the prime example, even though it is not a meta tag. You also should have a canonical link for all pages, even when that is on a canonical page (pointing back to itself). For example, if you look at the yahoo home page, you find this in the head. <link rel="canonical" href="https://www.yahoo.com/"> As for the meta tags they have the general form of (name, content) so a helper function could be: function makeMeta($name, $content): string { return '<meta name="' . $name . '" content="' . $content . '">' . PHP_EOL; }

Google by far generates the most organic search traffic, so it's best to focus on them, as most of the other search engines follow their lead in terms of how they score a page internally. Also the google search console is an excellent tool for getting an idea of what is going on with the indexing of your site. You should make sure you've gone through the steps to insure that every site you control is registered within the tool. The title tag is important. There's a rule of thumb being "12 words/70 character max". Google indexes only the 12 words, weighted towards the first 12. It will also only display up to 70 characters. The description tag is important, only so much as it will be displayed when it comes up in a search result. This is where you can "sell a user" on the relevancy of that page, since the description will show up with the result. Keywords and description are both things that google no longer uses, and were used in the past by people trying to game SEO, by putting in descriptions for pages that don't have relevant content to match the description, or a long list of keywords they "wished" the page in question was relevant for. Any decent search engine these days, parses the content of the page and uses a high degree of sophistication in determining relevance. You aren't going to fool anyone by listing a bunch of key words in the meta tag. Since Google hasn't even looked at them in years, many sites omit them at this point, and if that was a significant concern, you would see discussion of that. Typically if you look at SEO discussion, the main thing that comes up beyond proper use of meta tags is h1's, canonical vs. non-canonical versions of a page, and how to handle those, and having a sitemap (that you re-generate/add to whenever you add a new page to your site.) For indexing pages and internal link collections (for example a page on a blog that has all articles for a particular year, or a page in a catalog where you have all products within a particular category, the robots tag is a good one, and has advantages over using a robots.txt. You don't want non canonical versions of the same page, or pages that could lead to indexing of a non-canonical version along with the canonical version as this has the potential to reduce the overall score for the canonical page. Pages like that should typically include the robots tag. <meta name="robots" content="noindex, nofollow" /> More about that here. If you have video content then you want a video sitemap or mrss feed as described here I know that not all of this is directly related to your meta data question, but hopefully still generally related and useful.

Search engines just look at the final http response data. They have no visibility into the internals of how a page is rendered. There is no problem doing what you want to do, and in fact many cms's, forums and frameworks do this exact thing. Just to be clear, meta tag keywords are ignored by google, so you may or may not want to include those in your page rendering.

Since I'm more of a symfony guy, symfony has something very similar: webpack encore.

Yeah, certainly it's typical to have a whole set of relations you want to clone in most cases, so the entire premise here is simplistic, but an interesting challenge as is. DBAL provides an interesting option, where it will expand parameters. I'm playing with that at the moment, just to see how simple an app could be to do this somewhat generically.

I didn't think about doing it wholly with PHP, but yeah, that is a good way to do it in this circumstance. Just 2 queries, even though you have to read the result -- it's 1 row. The main concern I would have, never trying this, is that the columns must be in the correct order. You'd also have to escape the strings. It's a bit tricky, unless I'm missing something.