base64encode/DB replacing all "+" symbols with "space" ?

[FourthWorld]

To fourthWorld,
Are you suggesting that I should stop using base64encode and just replace it with:

binaryDecode("H*", tOHash, tHex)
...at uploading time ?
at both - uploading & downloading.?
..or just downloading time ?

All I'm suggesting is that when we look at how most people convert binary hash values to plain text, they usually do so with Hex rather than Base64. The latter is useful for many things, but mostly used when sending POST data. Base64 data often includes line wraps to fit in 80-char boundaries, but of course that'll muck up a GET request. Besides, as mentioned earlier everything in a GET query string is stored in Apache and most other web server logs, so if the query contains secrets it requires additional diligence to protect them. With POST only the URL is logged, but not the data.

Under what circumstances would you have a server deliver a hashed password at "downloading time"?

Is your server using HTTPS?

[teriibi]

Uhhhh
...after running some test I m now sure that the URLdecode is part of the problem and in fact, that is the one function Removing the "+" symbols and replacing it with space " ". !

the following code is causing the problem.

Code: Select all

  put URLdecode(toParse ) into fld "stringB"

While this one

Code: Select all

  put toParse into fld "stringB"

is (Now!) returning the string as it was sent including the "+" symbols

So..Ahhh thats part of the problem solved - both StringA and B now DISPLAY the same information on screeen - BUT still they are not equal (!!!)

I also added a counting string field...and although they display the same, they are diferent in size by 7 / StringA is 89 Car. StringB is 96 Car.

PS: Yes server is Https. I tried using binaryDecode("H*"... without success,

Code: Select all

   if fld "stringA" is fld "stringB" then

is returning false !

Now : DB field format is using VARCHAR(150) Utf16...

[teriibi]

look alike strings, but dif. in Characters counting size.

Code: Select all

put the number of chars of fld "stringB"&" car" into fld "TotalB"

What would be the next step to check the "under the hood" real size or format

[FourthWorld]

I also added a counting string field...and although they display the same, they are diferent in size by 7 / StringA is 89 Car. StringB is 96 Car.

A screen shot prevents us from analyzing those results. A sample stack would empower us to see the results directly.

I tried using binaryDecode("H*"... without success

The function works; the code posted above has been used many times in production.

Any issue seems to be with needing to match a value whose source I don't understand: where do the values of field "stringA" and field "stringB" originate?

If they originate from your own program, using the more common hex form will save a little space and eliminate all issues that can arise with Base64.

But if the comparison string was created by something outside your control, then of course we have no choice but to use whatever method was used to create those values.

[teriibi]

Yes, when mentioning that I was not succesful with the Bynarydecode, I meant I couldnt find a way to configure it to my "input value" case....not that the feature didnt work.

all samples I could find seems to relate to "hard coded" values while I m using "user input" values from my own LC stack´s fld, I tried to figure out out to adapt it ...to an "input" case but there seems to be too many params in the way..or params I dont know what to fill them up with ..so testing didnt produce any worth results at all.

As showing in above script copies... StringA/B are directly issued from a Hash 512 values.
The hash value could be built from a PW input or any other "input" values that I want to store localy AND on server, (as Hash).

StringA(from Server DB / stringB(localy kept) would then need to be compared - on client side - and - on demand only at certain times.
Sorry if that wasnt clear right from the start...

[MaxV]

Are the chars encoding the same?
The string are the same, so if the number of char is different, the bad char encoding produce not printable chars like numtoChar(1) or similars.

[teriibi]

Nop, since its user input, a minimum size limit can be fixed. and a Max one, but any string lenght will be available between those two.
DBs Field would also use VARCHAR for variable lenght.
I m not sure how LC functions deals with empty "remaining space" if I would use a Fixed CHAR lenght.
As long as it doesnt add "empty" car to the original string lenght it would be fine.

[dave.kilroy]

Teriibi, post your complete code here so we can see it, if we can see it we can probably help...

[teriibi]

the script itself is quite simple with 5 params..but I d like it to be tested against real https and DBs with php access.....else I d be posting only small part of the process here"..do you think you can run testing with such config ?

[teriibi]

Here we go !
This script was tested against my DB and works perfectly ..."except" for the light StringA/B difference that still makes them NOT iqual.
Any other "if then..." format comparing info is welcomed if that can solve the compare diffrence, using another string format...as long as it remains 100% reliable.

512 Hash send and retreive.zip

(2.55 KiB) Downloaded 465 times

http://www.7-zip.org/download.html

[MaxV]

please post the urlencode() of both strings, so we can see where are the differences.

[teriibi]

mmm. as I mentioned earlier, my use of UrlEncode was creating the problem, removing "+"..
therefore I decided not to use Urlencode anymore....which actually SOLVED the problem as for the "+"/"space" swtiching.
Note that contacting my hosting provider, they toldme just the same. UrlEncode should only be used for sending data over the web, NOt for passing params to Php to store values in a DB.

I guess many helpers - here - not knowing that this is what I pretending doing, were recomending a use of UrlEncode/decode that is intended for another type of use....
my Hoster says " don tuse it, it creates problem with "+"/"space" for what you are trying to do. so I ll guess I ll stick to their advise.

The only remaining problem for me now, is understanding what string format is LC actually measuring since the funcion for the lenght returne 2 diferent sizes of strings...although they display (in their respectiv fields) the same "visual content"...

I m not using URlencoding anymore, but if you need a URL convertion to understand it, I ll post it here in a min...

[teriibi]

That would be the URLencoded string of the Hash sent.
Its the Equivalent value of the input Value before Hash inside the Zipped Stack

M%82%06%EF%15%218%BFk%DA%7DP%1Fo%5Ek%1FM%10a%D3%8Ch%3D%9BC%7F%A6%CE%83%E7%141%94M%CCp%87%11%B0%B3j%FD%5D%3C%F0%EB%E5%B3%7E%1D%E8i%94Qx%FC%B6%A7%A1%5B%AE%931

Note, you can play with the zipped stak now, its the exact same script and procedure I m using....

TextEncode also replaced the Base64Encode...for the same reasons that I m not using URLEncode - as recomended by my Host Hotline Tech.

[FourthWorld]

all samples I could find seems to relate to "hard coded" values while I m using "user input" values from my own LC stack´s fld, I tried to figure out out to adapt it ...to an "input" case but there seems to be too many params in the way..or params I dont know what to fill them up with ..so testing didnt produce any worth results at all.

As showing in above script copies... StringA/B are directly issued from a Hash 512 values.
The hash value could be built from a PW input or any other "input" values that I want to store localy AND on server, (as Hash).

StringA(from Server DB / stringB(localy kept) would then need to be compared - on client side - and - on demand only at certain times.
Sorry if that wasnt clear right from the start...

Unfortunately my coffee this morning is weak so I'm still not getting it: where do each of these values originate?

I understand one of them is in a DB. Where did it come from? Is it something you generated and stored there, or was it generated by some other program?

[teriibi]

Hey Guys,
I ve posted the Stack zipped with full code,, just above ... are you testing it