requinix

Just because $name came from $names which is an array made up from those three variables, does not mean that you can modify $name and have that "work its way" back to the original variables. If you want to clean the $firstname, $lastname, and $username variables then you should clean the $firstname, $lastname, and $username variables.

Are you sure you put Ultimate.php in the right place? What's the code in that file?

...and the same applies to other functions, like strip_tags and str_replace and strtolower and ucfirst. They return new values and do not modify the variables you gave them.

I've tried dumbing it down. It hasn't worked so far. I don't care that it's "the same" (nor even know what it's "the same" as). I want to know how many bytes are in your key. Or bits. Same thing. Because if the number is anything other than the number I expect, that will influence how the encryption and decryption process works. So I'll ask again: how many bytes/bits are in your key? Then you have a problem because the code they gave you doesn't include a key. It also includes an IV, which is not used for (what I believe to be) .NET's default behavior of CBC mode, so either the IV is irrelevant or .NET is switching to EBC mode based on the presence of an IV. But that doesn't really matter much because it's only two possibilities to try out: with the right key, one of those two modes in PHP should produce the same output. Give me some real answers and we can make progress. I'll ask an earlier question again to echo what kicken said: create for yourself a new key that you can test with, then post it here so that we can all be on the same page.

And one more question: exactly how many bytes is your real key? There is only one correct answer to that question and I want to make sure I'm hearing it from you.

Okay, see, I'm going to have a really hard time explaining why your outputs are incorrect if I don't know what the inputs are. I get that you can't share your key, that's fine, but I need a key in order to verify whether something works. I'll try from a different angle. That C# code you posted. Is that exactly the code that was used to produce that WfRb encrypted output? If it is not the exact code, what is different?

So test your code with a different key. Go out into the internet and find samples encryptions to verify that your PHP code is producing the correct outputs. This isn't just about the C# anymore. You've got AES-256 in one place, DES is another, improper PKCS padding in your PHP where the .NET code doesn't do any... What information posted so far are you absolutely sure is correct?

With that same code I get "bimbcVvpJ/NBxllxxCsW+w==" for the encrypted output, and online sources do too. So I don't know where you're getting that Pt0MK string from, nor why you expect it to be WfRb. Also note that your key is the wrong length: a 256-bit cipher needs a 256-bit key, and if you don't provide one long enough then it gets padded with \0s.

Well, your key and IV are different, that could totally explain why you get different results. What key, IV, and input string are you testing with? What outputs do you get for the C# and PHP code samples?

(background information: by default, Composer assumes you want all the things you install to have a "minimum stability" of "stable", meaning the packages themselves are marked as being stable releases - as opposed to alpha releases, or beta releases, or "dev" releases) To see what's going on, follow these steps: 1. Take a look at your composer.lock file to see exactly which version of programarivm/php-chess was installed. You should see it as version 1.1.3. 2. Look at the repo's latest releases. You'll see that the latest version is 1.1.51. 3. For bonus points, try browsing the repo at version 1.1.3. Look at the instructions and compare with what you have done. Close but not quite the same, eh? 4. Rather than give up and go with an old version from last August, try telling composer to install version 1.1.51 instead: $ composer require "programarivm/php-chess 1.1.51" 5. Composer will complain about depending on rubix/ml being "dev-master" and how that conflicts with your "minimum-stability". The conclusion here is that since your minimum-stability is (the default of) "stable", and recent php-chess versions require a thing that is not stable, Composer won't install those. But you do want those. 6. Tell Composer that "dev" stability is fine. That might feel wrong but unfortunately this is actually a very normal thing to do because lots of developers out there don't do Good Things with their versions. $ composer config minimum-stability dev 7. Now have Composer update php-chess to the latest version. $ composer update programarivm/php-chess 8. Watch the update output to see what version it installs.

No, no, the point of what I said not about me doing the work. The part of that post you skipped over was "for the same reason", meaning I was trying to demonstrate the "that will not work" point using an example. I'll try some different examples, okay? Having PHP access the user's current version of the webpage at all - forget DOMDocument, that has nothing to do with any of this - will not work for the same reason as why you cannot 1. Fill your car's gas tank while you sit at home (because the gas is at the gas station and you are not) 2. Pull a turkey out of the oven while you are filling up your car's gas tank (because the the oven at home and you are not) 3. Climb Mt. Everest with a hot turkey you just pulled out of your oven (because Mt. Everest is in a remote location in Asia and your oven is not) Do you see the pattern here? The HTML table you want to access is located inside your user's browser while the PHP code is running on the server. To exchange data you have to exchange the data, meaning the client's browser (where the data currently is) has to be sent the information about the table/hex colors to the PHP server (where you want the data to be). Sending information from the browser to the server is done by either (a) using HTML forms, which you said you don't want to do, therefore forcing you into the only other option of (b) using Javascript and AJAX.

That will not work for the same reason that I cannot sit down at your computer and do this work for you: I am over here and you are over there and neither of us can see what the other is doing.

You have two options: 1. Use hidden inputs, like I said to do, so that the user can do whatever they want. I don't know what else they can do with the table. If anything - every single bit of information you've decided to reveal so far I've had to forcibly pry out of you and I'm not going to do that anymore. They do whatever with the table and cells, you use AJAX to send the current state of the form's "data" to PHP. 2. Don't bother with the hidden inputs because the user can't change anything once they hit whatever button. You have code that builds the table cells so it would be easy to (for example) insert those shadeHex values into an array as you go, then when the table is done you can AJAX that array to PHP. Either way, the point is you are sending data to PHP rather than having it try to go out and get the data on its own (which isn't actually possible to do in this case anyways).

Yeah, okay, that's the exact opposite of what I thought you wanted to do. Put the table into a <form> and use hidden inputs to identify each value. $ ( "#shades" ).append ( '<tr>' + '<td class="hexcolor">' + '<a style="background : ' + shadeHex + '"></a>' + '</td>' + '<td class="hexcode">' + '<input type="hidden" name="shade[]" value="' + shadeHex or whatever + '">' + shadeHex + '</td>' + '</tr>' ); Submit the form normally or with AJAX and you'll have an array of shadeHex (or whatever) values.

Okay... so if the table changes according to how the user interacts with the page, and you first said that you wanted PHP to get those values from the table, then how is PHP supposed to know how the user interacted with it? Is your question more about how to send the values from the table to PHP? Maybe the user did something and now you want the results of whatever to be handled by some PHP code? If that's the case then exactly what is the information you want? What is the user doing, anyway? And one more thing. If you haven't noticed, posting little bits here and there just means I have to keep asking more and more questions...

There has to be more than that - where are "shades" and "tints" coming from? And is there a particular reason this is all being done with Javascript? Is the user interacting with the page to change what values are being shown in the table?

Alright, we'll do this one step at a time. The shadeHex values. Where are those coming from?

I would do it the way I literally just said: by examining and reusing/adapting the code that index.php is currently using to get the data.

You're trying to grab data from your own site. You have some PHP code responsible for outputting data into the table, right? Don't you think it would be easier to mimic that code that gets the data rather than do this complicated thing of executing the PHP, parsing the HTML, locating the correct table somewhere inside it, and extracting parts from it?

$stream = fopen ( "index.php", "r" ); Are you trying to read an HTML table that's outputted by a page on your own site?

Don't even consider operating system users. Should have absolutely nothing to do with the people on your website. Users should have some sort of account on your site before they get a token. If they didn't then how would you know which token corresponds to which user? If you have a framework and it provides authentication then you should use that. If not then you can't really do that, can you? Do you want simple or do you want secure?

Can I assume you mean that you use POST when performing certain operations, such as when someone wants to add inventory to the site, and that you use regular GET when it comes to simple browsing? Because it doesn't sound like that's the case. And it should be.

If title.php is the only place that knows what the new title needs to be then you'll have to make an AJAX request to it.

You were frustrated. I knew you could get the answer on your own with a little prodding, but if I didn't prod hard enough then you might just get upset at me stringing you along. So I figured a long post you had to read through that explained, but yes ultimately gave away (kinda), the answer was a decent middle-ground.

Undo everything you installed manually, reinstall through apt. Ubuntu 20 supports PHP 7.4 so you should be fine.