gizmola

I am not great at that either. I have 2 2015 Macbook Pros I use, both on Mojave, but I have decided not to try and upgrade them to Catalina, as I read that it broke a bunch of 16bit apps, and I don't want to spend time or money trying to upgrade things that currently work fine for me. The main thing I am wondering about is that you are starting up a cli app, and there are some other vsc settings that might be relevant to the cli like: program: Path to the script that should be launched args: Arguments passed to the script cwd: The current working directory to use when launching the script runtimeExecutable: Path to the PHP binary used for launching the script. By default the one on the PATH. runtimeArgs: Additional arguments to pass to the PHP binary externalConsole: Launches the script in an external console window instead of the debug console (default: false) env: Environment variables to pass to the script

It's fairly obvious I think. Your $text variable has single quotes in it. You are then trying to insert it: $db->query("INSERT INTO gangevents VALUES(...,'$text')"); Because you are not escaping the $text, you have conflicting single quotes because at runtime the $csscode... becomes: viewuser.php?u=666' id='member' Notice the single quotes around 'member'. Really you should be changing all your code to use parameters. That is a countermeasure for SQL injection exploits AND eliminates the need for you to escape input. But in the near term you could fix this by making sure that the code that generates id='member' instead generates id="member"

What OS is your workstation?

The Rewrite looks fine to me. Oops, yeah should be (list|gallery) For aliasing I would suggest that rather than using rewrite, use mod_alias with the alias_match directive

Maxxd is right. You should never do this, but it's a common mistake that is hard to recover from unfortunately. You should always store datetime values as UTC, and this should be the timezone of the server OS, php and mysql. Once you know it's in UTC, you convert the date using a timezone for the purposes of display.

This is one of the reasons I don't use bactics around column names unless they are absolutely necessary (wihich is rare). $query = "UPDATE greencard SET comments = '$comments', sent = '$sent' WHERE hospitalnumber = '$hospitalnumber' and PIN= '$PIN'"; Make sure that follow Requinix's instructions and change this code to use parameters and prepared statements. There is no excuse to write new code this way!

This thread has already gotten really long winded so I'll try and conclude with some final cherry picked replies: PCI Compliance If you have a server in the cloud you simply can't be PCI compliant. You aren't really allowed to handle credit card data yourself -- but instead utilize the payment processor. This essentially reduces your concerns at the PCI Level 4 merchant level (or below) to doing a self assessment document. All you get from a payment processor, and will be allowed to store and use subsequently is tokens. Tokens aren't hashes either -- but are instead single use (nonce) keys that let you interact with the payment processor. At any point along the way if you are storing the original credit card input, you are at risk of running afoul of pci dss which you don't want. You can't store the cc info, even temporarily in a session variable to make the form process work nicely. This is one of the reasons that just about every modern payment process has a final step where the payment information is dealt with separately, and why the cc info is not retained between calls to the gateway. You wrote about how you would do subscriptions without doing subscriptions, which basically means that you will have to start messaging people about their pending renewal, and when it gets around that time, you will need to do a new transaction where they enter all their payment info again as if it was the first time. You kind of positioned this as a badge of honor, but it's a really poor decision for a subscription reliant business. I literally have never seen a single subscription business that involves that design. The hash in support of the ban tool You could go ahead and do what we've discussed, and take a piece of the cc# along with other pieces of name and address and make a hash and store it. You could also check against your own table of fraudulent credit cards and intercept a potential transaction before its sent to the gateway for that matter. You just can't store any of the inputs being provided to you persistently. Is a hash based on a piece of a cc# useful? Numerous people have pointed out the same issue, which is that people can have lots of different cc and cc#'s. The thing that Requinix described is not some esoteric product, but offered by large banks like Citibank, Capital One and Apple (backed by Goldman Sacks) to name just a few. It lets a customer go in and generate a disposable card#, ccid and expiration to be used for one or more transactions online. It's existence entirely defeats your hash. In fact it suggests that adding in any part of a cc# makes the hash less effective. Given these facts, assume you go ahead with your original idea. How will you create this table of "bad hashes" in the 1st place? Are you going to make a hash for every paid user stored with a flag that is 'ok' and then flip that to 'banned' or something like that? If that's the case then you would have with sha1 for example, to store a 40 character string in your database for every single user, just so that you can flip that on a handful of users at some future time. That's a lot of storage for something that would be used infrequently. Is a billing address required for ecommerce? I can only answer this technically having implemented e commerce numerous times with different vendors. With some of the largest payment processors in the marketplace, the address is not part of the input to the gateway. You may do with that what you will, but again, if I'm not shipping you anything then what do I need your address for? I brought up the gas station example, and your reply was that the card was present. That is true, but why then are they asking for the zipcode? It is because the card could have been lost or stolen. It's just an additional check. With ecommerce, the entry of the ccid is the equivalent mechanic that validates the card is present. You should also know that credit card fraud is *your problem*. Most of the payment processors offer their own fraud prevention services that you can pay for or not. There is no built in visa/mastercard/amex/discover fraud prevention system you just get automagically. Fraud = chargebacks, and chargebacks are bad for your business and will cause your per transaction costs to go up, or can even lose you your merchant account. Payment tech is changing Younger people are using mobile payment tech like apple pay, google pay, samsung pay etc. There is also a long tradition of alternative payment options, with the most prevalent being Paypal. Most people that take payments are going to support paypal, and you might also like to support these newer technologies at some point, and none of them have credit card #'s. Legalities There is a lot of state and federal consumer law out there. Just because you put something in a TOS that takes away someone's rights doesn't mean that will stand up in court. My final word If you want to do what you originally brought up, then technically it can be done. Requinix wouldn't if it was his company, and I wouldn't if it was mine. I just don't think it would be worth the time, effort, and storage cost, even though it could be coded up relatively quickly by someone who understood all the parts and technologies well. Furthermore, if I wasn't stuck in my house right now, I doubt seriously I would have continued to engage in this conversation given the mysterious nature of your proposed business. I don't want nor need to know what it's about, but I just have my doubts that there is any online community that people will pay for, when there are numerous well established online communities out there that are free. Usually the devil is in the details for any online business, and it's just not very fun or interesting to tech people to try and guess about what feature might help you enforce rules, without understanding the game afoot. Get your MVP up and running and then if you want, you can come back armed with specifics and actual real customers, and you'll find people a lot more enthused about your ideas, whether they be viable or not.

When I stated you don't need a billing address for a cc transaction that is because it is not input that is checked, thus it is optional. Consider how cc's work in the world. When you go to buy some gas for your car at the pump and insert the card, do they make you type in your billing address? Consider the many ways that the same address can be entered. Any matching that might be done on address would be fuzzy at best. Again even with the same address (and I'll assume you would uppercase the input, because any variation of even letter case generates a different hash) I can vary my input slightly to get around your mechanic some number of times. Bob Smith 232 River View Lane Grand Rapids, MI 83293 Robert Smith 232 River View Ln Grand Rapids, MI 83293 Robert Smith 232 River View Grand Rapids, MI 83293-3233 Robert Smith 232 River VW Grand Rapids, MI 83293-3233 Now I don't think people are going to do this to try and get around your system. Quite frankly I don't think any legit user who you just banned (and I would think you would need to probably refund at least the remaining portion of their fee or likely face legal challenges) is going to turn around and try to sign right back up again. Won't happen, so what is the point of creating a complicated and tempermental feature that isn't actually going to stop anyone who is persistent from resubscribing? As we've already established, all they would have to do is just use a different cc#. That's not reverse engineering anything. That is using intimate knowledge of system internals + a person's name, which in this scenario we are assuming your whole system database got dumped. Yes it would be trivial for me to create a rainbow table of 10000 entries for every name in your database, all so that I could establish? The last 4 digits of an unknown credit card? Now let's say that they got hold of this table or column of hashes with no idea what they were used for. Can they be "reverse engineered?" No. Someone could try and generate a collision value, but that has no value in this use case. It's just another set of input that will generate the same hash (or the original input, although if created randomly, the person running the computation wouldn't know). If you wanted a larger hash, you could jump up to sha256, but that sort of decision ought to be made because you fully understood at least at a layman's level, how the hash works, what the pros and cons of it are. At this point, the only reason I'm continuing to elaborate is to hopefully incent you to spend some time researching these things yourself. This is the reality -- if your system is so deeply compromised that all the data and source code and key values and salts you might be employing are known to them, they likely have full control of your entire infrastructure and can just siphon off all of your transaction data in real time or shut your system down, encrypt all your data and hold you hostage.

I assume from these questions that you are on shared hosting? Since you want this processing to take place for any requests that might be coming in, I would place it at the top of your htaccess and see if it works or not. You don't want to manually code in ob_gzhandler() calls for your pages if you can have apache take care of it for you. Ideally, you just want the configuration to be serverwide or at very least vhost wide, but perhaps that isn't possible for you, so in that case a htaccess statement at the root of your site would be preferable.

This is a well articulated explanation of the point I was trying to make earlier about making things overly tough for the paying customers you want (the 99.5%) in order to police and provide barriers for the .5% you don't want. History has shown that this is a bad business model. You have to be very careful about alienating the customers you want. If we once again return to the questions you've posed about "security", for your purposes a hash is secure. You can not take a hash and determine what the input was that created that hash. md5 and sha1 are often used for fingerprinting of things to determine if they've been tampered with. A pdf document for example, uses sha1. In the bad old days people often used md5 and sha1 to store passwords, and what would happen is that if the system got compromised, perhaps through a sql injection issue, then the entire list of user account password hashes might be disclosed. In those days crackers would have pre-generated rainbow tables of all sorts of common words phrases and names that people would use in the bad old days. A quick check against the table for a large membership database, and I might find 10% of the users had bad passwords that matched hashes in a rainbow table. Those crackers could then, perhaps with an email address in hand, try the same password on other systems, and people being naive as they tend to be, often reuse the same password across systems. In more recent times supercomputers and high performance gpu clusters have proven to be able to do incredible numbers of hash calculations per second, so they can attempt to compute enough hash values to find a hash collision. This is not knowing the original input, but rather crafting some input that computes to the same hash value. I don't need to know the original password, but I have something just as good, which is a password that will still match. For this reason, people have stopped using md5 and sha1 as computed password values, and the industry has moved to techniques that are slow to compute. None of this is relevant to the use case you prevented of having a fingerprint value computed from portions of a user's personal information. So if you were to take a bunch of input (name, address, partial cc#) and hash it with sha1 or md5 along with some other input like a "salt" value, and store that in a database, you could use that later to see if some new user info matches a "banned" user. Yes you could do that. But can you reasonably expect to ask people for their full address for an online account when they aren't required? Unless you are shipping me a product, you don't need my address. What you need to get a payment from me is: -Name on the card -cc# -expiration -ccid -billing zipcode (usually for a higher level of fraud detection, but likely irrelevant for your online system). A lot of people are going to balk at giving you address information without an understanding of what you plan to do with it, knowing that you will store that information in your system and not do anything with it which just opens up the possibility that my personal information might be stolen from you at some point in the future. There's risk, but what is not clear to any of us, is what it is about your system that represents a reward substantial enough to pry information from a significant user base. You asked about how and why cc processing uses nonce values. It's exactly because as you already know, PCI compliance is expensive and out of reach of most businesses. It is simply a better work around to take input securely and pass that to the cc processor securely, who then issues you back a nonce for the transaction. The payment processor stores the cc details on their system, but you use the nonce they gave you to proceed with the rest of the payment process you need to eventually get a transfer of funds from the credit card issuing bank to your bank. In the US, given the way laws work that usually doesn't happen for 30 days anyways. You are not storing any personal cc info, and they don't want you to. In order to establish any recurring payment, you have to use a feature the payment processor provides to you where again, you will not store the cc# but they will on your behalf. Needless to say a lot of things can go wrong with recurring payments -- the card could be cancelled, it could lack funds at processing time, etc. etc. Lots of people are pretty savvy these days and have had bad experiences with services that they can't unsubscribe from, so again you better have something people really really want badly in order to sign up for a subscription. You could siphon off a portion of the cc# and store the last 4 digits, but I don't find that substantially more useful than the input you are already going to ask for, and at the end of the day it's a half measure that I can predict might catch a couple of people at most, and do nothing to deter anyone determined to get around this check, so at best it can only be one of many.

Given your comments, I understand your concern. If you get to the point where your community is successful enough to have the issues you describe then you can pay people (or in some cases entice them to moderate for free) your community. This is how this forum works. The forum software does have tools that will blacklist emails and ip's, but neither of those are fool proof. They still make it an annoyance for anyone who has not automated signups. The average crackpot will simply move on. The other thing that we face like most sites with any significant user base, is attempts to spam or advertise. Again our small volunteer moderation group, along with the forum's ability for people to report posts they think violate our rules insures that we have almost no spam or abuse presence on the forum lasting for any significant amount of time. More often than not, if I see a report, it has already been handled by one of the other volunteers. Again, having too many users with some that won't follow the rules is a good problem to have. I simply happen to believe strongly that it's more important to concentrate on your MVP, and building your traffic and user base than it is to try and engineer a solution to a problem you don't yet have, when you haven't implemented the tried and true, if imperfect, controls that other sites utilize first.

Just to go back to the original question, I'm not sure you are clear on what a hash actually is. A hash takes input and computes the hash. Hashes are not encryption with associated decryption. You can not decrypt a hash. They are also not part of php per se, but like most languages well known hash algorithms are available in php. Assuming you had a good use case for a hash, then md5 and sha1 are popular options. The more unique input you provide to the hash, the better it tends to be.

Yes this idea is DOA. First of all, people are loathe in the modern era to provide identifying information. The less information you require to establish an account the better, if you want people to sign up. People provide information when they have an incentive to do so. A "community" where people won't join because it's too much of an annoyance to join will be a ghost town. In my experience it's hard enough to get people to pay for a service, even a well executed one that people use everyday. Before stackoverflow, there was experts exchange. It was once a thriving tech expertise community, then they tried to monetize it by obfuscating the content unless you paid. This really pissed a lot of people off, and the site went rapidly down hill until it eventually went bankrupt. SO was started partially in response to EE's poorly executed paywalling scheme, and the rest as they say is history. Candidly I have been asked many times over the years to come up with ways to prevent people from getting access to a system or to content. This goes back to days I worked in the gaming and entertainment industry. There are some interesting case studies as to the effects of over emphasizing piracy or restricting access to content they have paid for, and in every case the employ of those technologies harmed or hampered the business over time. Meanwhile competitors that wrote off the concern thrived and often overtook competitors that at one time were the market leaders with a huge competitive advantage. The harder you make things for your users/customers, the worse off the business will be over time.

Yes the code is equivalent, but as ob_gzhandler() is a simplified shortcut, that would be preferred by just about anyone. Yes you can specify mod_deflate in an htaccess. <IfModule mod_deflate.c> <FilesMatch "\\.(js|css|html|htm|php|xml)$"> SetOutputFilter DEFLATE </FilesMatch> </IfModule> There are various analysis sites you can use to examine the output from your server like https://webpagetest.org/

Session variables are stored (by default) in files on the server. PHP automagically (re)connects you to that data via a cookie with the name PHPSESSID. It is an extremely simple and effective mechanism. The actual contents of the data in the session file(s) is the $_SESSION array that has been serialized by the php serialize() function. I hope that helps clarify what is going on. I did notice that you mentioned the word "select" in one of your replies, suggesting that there is some database involved. Simply stated, when you start a session, any changes you make to the the $_SESSION array in terms of adding or removing elements, is stored in the session file, and will be available upon session_start() on any future visits to the server where the browser presents the same cookie. If things aren't working on page #3 AND you are not overwriting or removing the value from the $_SESSION array, then you probably have a problem somewhere else. If you just wanted a simple example system, then I would steer clear of introducing a database into it, although I understand that a typical next step for people is often to make a login system. Not sure if this is the case for you, but your use of the word "select" made me curious as to what you are actually doing, and whether or not this has anything at all to do with sessions.

What does too long mean? You will more than likely have better luck with a maintained component based package, than trying to get one working that was originally in pear and has long ago been abandoned.

The exec/system/passthru/shell_exec calls will allow you to run external programs or shell/os commands. So yes, it should be possible.

I think you have to answer some questions that perhaps you have not even thought through: When Linda uploads 4 pictures, followed by John uploading 20 pictures, while at the same time Fred is uploading 40 pictures, how does the system know the difference between these 3 users? Most gallery systems just deal with the date the picture was taken in terms of keeping them together in groups, as they naturally can store them based on the date/time the picture was taken. Obviously you can have multiple pictures take at the same date/time but you really only need to add to the name a small randomly generated piece to be able to store multiples, and the chances of 2 pictures (in a small gallery) being taken at the exact same second is usually an edge case. Databases have thought through a lot of the issues with concurrency (multiple users trying to manipulate the database at the same moment while perhaps others are trying to read out information) as well as ways to provide fast access to a subset of the information. With that said, you could also develop this entirely without a database by using a meta file. Xml, yaml, ini and json are all popular file formats that can be read and written to via php. Without a database, you could store a meta file of the same name, only with a different extension, to store the information about the file (original filename, user etc) which could then be read to service display of the gallery or whatever you are engineering. A big advantage of that is that those files will be very small compared to the actual images and can act (as a database row would also act) as a standin for the actual images when you are displaying or sorting the gallery. The other thing to keep in mind about images is that php also can read the exif data from an image, so that opens up some interesting features that might let you introspect the information from the picture. For example, the FileDateTime timestamp of the photo maintained by the camera or phone.

You need to get the original files from source and replace that file if it pre-existed, not just edit it. The name seems odd to me. If it did pre-exist then you need to replace it, but otherwise it should be deleted. This is a big reason why you need an off server backup of the filesystem and database (I use dropbox), especially for a package like wordpress. Any popular application like wordpress is a target for crackers, as there are so many potential sites out there they can exploit using worms. As Requinix already advised, there could be a lot of issues with your server at this point that go beyond wordpress. They want to use wordpress to get enough access to install a rootkit where ultimately they have complete root access to your server. Often this is done to make your server a node on their botnet they can control to do things like send spam, launch DDoS attacks, store files on darkweb servers, and all sorts of other things many of which are criminal in nature. You really have to be concerned as to how badly your server has been modified. A rootkit replaces many of the essential operating system files -- things like the login program, ps, ls, ssh_d etc. Are you competent enough as a sysadmin to be able to determine the overall state of your server?

The other thing this tells you is that the permissions on your wordpress install are overly permissive. This is an unfortunate issue with wordpress in general in that it is certainly easier to allow it to have write permissions to be able to update wordpress through the admin console, but really those directories should be read but not write. Any small mistake in any of the components of wordpress, and you get these type of exploits. Once a cracker can get an exploit script to be written to the tree and included, it typically has the same permissions as the effective webserver user, and as requinix stated, at that point they probably also have the ability to get into your database. That's another mistake that people make with database users. Your wordpress should only have a user created in order to run wordpress, that only has permissions for the wordpress database, but all too often people do stupid things like using the mysql root user or a user that is shared across applications and multiple databases.

One other more general comment, but the way you have named your script implies you are either currently or planning to load data via ajax. Ajax will be a lot easier to work with if you return your data as json, and generate your markup code for the options in your clientside scripts, rather than echoing partial html.

I will admit I'm somewhat mystified as to what you are going for here. You have these queries separated via a chained if - then elseif which is somewhat odd. With that said, we don't have the markup for the select attribute, which is where I would guess the problem lies. I don't know if you are rendering it with javascript, but it's a pretty good guess that you have a naming issue for the 3rd query, where the name of the select is not named correctly. Your diagnostic at the bottom should have revealed that. $query = "SELECT * FROM platforms WHERE version_id = ".$_POST['version_id'].""; Another possible issue is that the table structure is incorrect or there is no data in the platforms table that matches the criteria. Again, we don't know what your database class actually does, or if it has any error checking for SQL errors since all we have is wrapper code like this: $result = $db->query($query);

I think it might be good to really read about the functions you are utilizing. The ob_* functions, like their name are there to buffer output which I'm sure you know. It's clear you are wanting to do this to gzip output, so why not use ob_gzhandler()? Better yet, let Apache use mod_deflate to do this for you? Tasking PHP to do the compression is less efficient than having the webserver do it, and again depending on your web server stack, is going to increase the memory footprint of your individual php processes. Delivering the html is really the job of the webserver, not php. I would always start_session() first.

Also there's DBAL which is part of Doctrine2. Well to each their own.

I agree with Barand and requinix -- either use the functions in MySQL or use a DateTime. With that said, your code didn't work because you inexplicably added a line to turn a perfectly valid timestamp number back into a string, and then tried to subtract it from the timestamp number. If you hadn't done that your code would have worked! <?php $row['date_ts'] = '2019-08-01'; $date_ts = strtotime($row['date_ts']); //Timestamp $totalTime = floor((time() - $date_ts)/(60*60*24)) . ' days';//Total in days echo $totalTime; // Outputs 259 days