Jacques1

No. You must properly integrate your page into the application infrastructure like all other pages (however that works).

It doesn't make sense to use Ajax and then reload the page. All that gives you is a bloated reinvention of plain old forms. The point of Ajax is to not reload the page. Regarding the concrete issue, you should read the documentation. You can't just randomly add a “success:” to your code. The third parameter of the post() method is the success function.

What is the exact value of $total1? var_dump($total1); What exactly have you tried? var_dump($total1 > 0.0);

One database, one table per relation, one column per attribute. So no duplication at all. And, yes, you would add a company ID to the rows. What do you expect to gain from creating multiple databases or tables with the exact same structure? I definitely know what you would lose, namely the ability to properly manage your server. Whenever you want to update the database structure, you have to do it n times (in the worst case, you even end up with different versions for different companies). Whenever you want to back up your data, you again have to do it n times.

As to the original problem: The code makes no sense, because you can only check if a variable is set. You're trying to apply isset() to the logical expression $_POST["submit"] == "Sign Up", which cannot be interpreted in any meaningful way. What you probably meant to write is a combination of two checks: // is the submit parameter set, and does its value say "Sign Up"? if (isset($_POST['submit']) && $_POST['submit'] == 'Sign Up') { ... } However, this is very poor practice, because now your entire processing script relies on one stupid submit button and its exact label. Simply checking for the HTTP POST method as demonstrated by benanamen makes a lot more sense.

You should have one database.

$_FILES

You should construct dynamic queries with prepared statements. Not only does this solve a lot of security vulnerabilities. It would also fix your current problem without any extra checks, because if $attributes['id'] is null, a prepared statement maps that to an SQL NULL, which is a perfectly valid value for an auto-incremented integer column. Your code, on the other hand, wraps all values in quotes, so you end up trying to insert an empty string into an integer column.

Are you sure that the data format you're sending can even be processed? As requinix pointed out multiple times, your format is vastly different from the example; until now, you've essentially just created a database dump in JSON rather than a purposely crafted payload.

I hope that was a joke. Do you have any idea what the OP even asked for? Not to mention the big, fat SQL injection vulnerabilities. You realize that POST data comes from the user, right? It can be changed to absolutely anything, including SQL commands.

PHP (unlike many other languages) doesn't support multiple form fields with the same name. You have to use a special array syntax instead: <form method="post"> <input type="text" name="foo[0]"> <input type="text" name="foo[1]"> <input type="text" name="foo[2]"> <input type="submit"> </form> This turns $_POST['foo'] into an array containing the three field values as elements. To get the data you expect in your script, you'd use a layout like this: <form action="insert.php" method="post"> <!-- first entry --> <input type="hidden" name="data[0][extension]" value="this is where the escaped(!) extension goes"> <input type="hidden" name="data[0][secret]" value="this is where the escaped(!) secret goes"> <select name="data[0][mac]"></select> <select name="data[0][template]"></select> <!-- second entry --> <input type="hidden" name="data[1][extension]" value="this is where the escaped(!) extension goes"> <input type="hidden" name="data[1][secret]" value="this is where the escaped(!) secret goes"> <select name="data[1][mac]"></select> <select name="data[1][template]"></select> <!-- etc. --> </form> Now $_POST['data'] is an array of associative arrays which can be iterated like this: foreach ($_POST['data'] as $entry) { var_dump($entry['extension'], $entry['secret'], $entry['mac'], $entry['template']); } But before you do anything, you need to clean up your code. This is a mess of security vulnerabilities, obsolete features and useless repetitions. For example, the <option> lists are always identical, so they should only be created once and then reused for each entry. It doesn't make sense to send run the same query with the same results over and over again.

What is this data format? JSON? Then treat it like JSON: <?php // test data $data = [ ['7C6Buh',37.4192,-122.0574], ['7C6Buh',34.147,-118.1392], ['7C6Buh',23.7231,90.4086], ['7C6Buh',39.9543,-75.1657], ['7C6Buh',32.7787,-96.8217], ['7C6Buh',37.4192,-122.0574], ]; header('Content-Type: application/json'); echo json_encode($data, JSON_PRETTY_PRINT); The JSON_PRETTY_PRINT option automatically formats the output. However, this increases the size and doesn't make a lot of sense when the data is read by programs rather than humans. You also need to learn how to safely pass data to queries with prepared statements.

How about you post your form (or at least the relevant parts), the processing attempts you've made and the exact problems you have? Nobody is going to write a PHP tutorial just for you, especially when it's entirely unclear what you even have trouble with.

I think I've found the problem: The open() function of the session handler receives your literal path parameter “4;/hermes/phpsessions”. It's then up to the class to resolve the subdirectory depth stuff. Since it doesn't do that and just appends the file name to the path, you end up trying to write files like “4;/hermes/phpsessions/sess_1234”, which is of course nonsense. The class cannot handle empty path settings either (which should be interpreted as: use the default temporary folder). So my guess is that the server admin has at some point changed the session path from a physical directory to the “4;...” setting, and that's when the class broke down. Long story short: Get rid the class or turn it into a simple wrapper for the standard session mechanism. The class right now is hopelessly broken and doesn't seem to offer any benefit at all; reimplementing it correctly will waste a lot of time, and I don't think anybody is willing to accept delays for that.

You should have told us a bit earlier that you're using a custom session mechanism. In that case I suggest you create a minimal test script without the class using nothing but standard PHP sessions: <?php session_start(); echo 'Session ID: '.session_id().'<br>'; echo 'Cookies received:<br>'; var_dump($_COOKIE); echo '<br>'; echo 'Session:<br>'; var_dump($_SESSION); echo '<br>'; $_SESSION['foo'] = 'bar'; Clear your cookies and visit the page. Both the cookie array and session data should be empty. Check your browser if you've received the session cookie. Then visit the page again. Both the cookie array and the session should now be filled. Also try different browsers. And temporarily disable session.cookie_secure. In any case, stop insisting that it's a HTTPS problem. That might be the cause, but it could also be something entirely different which happened during the update. Since you have no server access to actually find out, you should be very careful with assumptions. The session class definitely has not been implemented correctly. It doesn't even lock the files, which means concurrent accesses will trample each other. I'm not saying this is the reason for your current problem, but it's something you need to be aware of and which has to be fixed. What is the purpose of the class, anyway?

XAMPP on a Windows desktop PC has nothing to do with an actual webserver running a server-oriented Linux or BSD variant. This is fine as long as you're just using simple features that work everywhere. But when you want to customize the environment by, for example, installing the sendfile module, there are huge differences. On Linux/BSD, you simply install the module through a package manager or compile it with a single shell command. Apache modules are made for webservers, so installing them on a webserver OS is usually painless. It's very different on Windows: Maybe there isn't even a Windows-specific version. Maybe you have to install a C compiler. Maybe you have to go through a lot of extra steps to get the module to work. Maybe it doesn't work at all. Worse yet, those steps are often poorly documented, because developers don't necessarily expect you to run their server software on a Windows PC. Even if you do manage to make your application work on your PC, there's no guarentee that it will work on an actual webserver. When you upload the application for the first time, it may just crash, and then you have to invest a lot of extra time to convert back and forth between your Windows version and the Linux/BSD version. Yes, I recommend you install a typical server distribution (e. g. Debian without a GUI) in a VM and simply try it out to get a basic understanding of webserver administration.

You'll need to be more specific than “the code breaks”. What is the exact error message? If there is none on the screen, check the PHP error log (wherever that is on your server). Also check the inputs: var_dump($ending_date, $starting_date); Are those even valid?

Just to make sure we agree on the terminology and concepts (because some parts of the original post sound strange to me). With “production server” I mean the public webserver which you have rented (or will rent) to host your website on the Internet. You would never install XAMPP on a production server, because a) XAMPP is meant for developer PCs, and b) it's just not necessary. When you rent a webserver, it usually has Apache, PHP, MySQL etc. already preinstalled, or you can easily install this software with a package manager. The OS on a public webserver must obviously be stable and secure, so common choices are Debian, CentOS, OpenBSD, ... When I suggested a VM, I meant a local test environment to replace your current XAMPP setup. A test environment should match the public webserver as closely as possible. So if your public server uses Debian, Apache, MySQL etc., then you would install Debian, Apache, MySQL etc. in the VM. The VM doesn't need a desktop GUI, because you just use it to run your application. The actual programming still happens on your Windows PC (or whatever it is you're using). If you want a Linux desktop for programming, that's another story.

TLS is optional on port 587.

The save path looks odd. Are you sure that the session is actually persisted to disk? Also check the PHP error log.

The tokens are generated with a cryptographically secure random number generator, so unless your operating system is fundamentally broken, the risk of any collisions is insignificant. It's as unlikely as somebody generating the same RSA key as the one you use for TLS.

You should not edit any libraries files. If you just want to change the table names, you can do that through the configuration parameter of the constructor. If you want to change the entire table structure (for whatever reason), you can create a subclass of OAuth2\Storage\Pdo, override the methods and use that subclass as your storage engine. Last but not least, you can write a storage engine from scratch by implementing the various storage interfaces (see the documentation). You do not remove any files. A library is by definition a collection of features which you may or may not use. The features you don't use have no effect. If you essentially want no user interaction at all and instead delegate authentication almost entirely to the app, the password approach doesn't make much sense. Depending on your app and audience, 6 months may already exceed the total lifetime of an app instance. There are many authentication options, not just passwords. There are client credentials (basically a single permanent refresh token), JWT Bearer Tokens etc.

Nothing prevents you from restructuring the result in your application: <?php // test for query result $result_set = [ ['type' => 'Leveler OTH', 'type_count' => 14], ['type' => 'Leveler OTD', 'type_count' => 42], ]; // new structure $counts = []; foreach ($result_set as $row) { $counts[$row['type']] = $row['type_count']; } var_dump($counts['Leveler OTH'], $counts['Leveler OTD']);

The query is still a bit strange, though. What is the “id” column supposed to say? There's no grouping by that column, so the value is undefined. In strict mode (and almost all other database systems), it's not even valid to select this column. And why do you need to count each type “manually”? The standard way would be to just group by the type: SELECT type, COUNT(*) as total FROM ofthes_winners WHERE userid = ? GROUP BY type This gives you the count for each type: type | type_total -------------+------------ Leveler OTH | 14 Mugger OTH | 42 ... You can get an additional row with the overall count through WITH ROLLUP. Sure, the result set is layouted “vertically” rather than “horizontally”, but that shouldn't be an issue.

Have you read the documentation? The callback must be a JavaScript function which is called when the user tries to solve the CAPTCHA and has a single parameter for the user's response (g-recaptcha-response). This response must be sent to the server along with the actual form data and then verified. Your system for form submission is rather strange, though, so I cannot comment on how to actually implement the function.