Setting the padding mode doesn't pad existing data - you need to start by getting the raw encrypted data (before it's translated to Base64 and feeding that into your decryptor.
If that works - and produces an output that is identical to the original input - then do the base 64 conversion each way and check that works. Then compare the Base64 strings against the string passed to your method.
If all of that is right, check the Key and IV byte values against those you used for encryption.
The debugger will give you all that - but we can't do any of that for you - we have no access to any of the information you are passing to the decryptor!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
I have found the problem using debug and it was my own silly mistake.
I was using the code:
for(int i = 0; i < DataGridView1.Rows.Count; i++)
DataGridView1.Rows[i].Cells.Value = Decrypt(DataGridView1.Rows.Cells.Value.ToString());
As you can see each row was getting the value of the first row. So on the first row it was decrypting the string but on the second line it was trying to decrypt the first row that it had already decrypted. Hence the error.
I think I need a break that was quite embarrassing.
Thanks again for your help.
It would be great if you can share the document that is being fed to the ChatBot — the root cause for the "html" is not declared. It is hard to debug it this way, you can read the output of that request and share it here.
And never share the credential on the internet (your SO thread has the credential of your MVP-based profile), and avoid sharing the email address unless you want spam in your inbox.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
Although it is difficult to give anything without knowing the context of the usage, but a service principal is what you are looking for if you want to use AD for authentication. Service principal and Azure AD OAuth can be used to automate the login process (check the last link I provided below).
Since NAT is involved, did you setup a rule in your NAT engine which allows clientB to directly connect to clientA, and vice-versa?
You should check the log of the NAT equipment and search for dropped or refused packets from clientB's network to clientA's network.
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
If i add rule to Port Forward external ports on Client_B and Client_A, the Client_B can successfully connect to Client_A.
But i need to make this work on nat routers that I don't have access to the settings so I need to make it work without port foward.
Checking the Router(Nat equipment) not show any info from dropped/refused packets but I think it's because it's not a good router.
Sorry for bad english.
Last Visit: 28-Mar-20 8:19 Last Update: 28-Mar-20 8:19