Restore password decoding

[benyjr]

As @Angel0ffDeath discovered, the password is base64 encoded when setup.sh is run. Thus you can't just pass the encoded password to the field, it won't match the correct password. ele_pwd.send_keys(base64.b64decode(self.password).decode('utf-8')) will decode the password back to the acceptable text.

[neothematrix]

thanks once again @benyjr and @Angel0ffDeath will the script keep working even if the password is NOT base64 encoded? I.e. if you directly call the no-ip.py script with the plain text password?

[Angel0ffDeath]

thanks once again @benyjr and @Angel0ffDeath will the script keep working even if the password is NOT base64 encoded? I.e. if you directly call the no-ip.py script with the plain text password?

Make a check - if last symbol of pass string is '=' then base64 decode else plain text. And user should not use '=' as last symbol of plain text pass :-) :-) :-)

[neothematrix]

can I suggest this instead? https://stackoverflow.com/a/55985185

[Angel0ffDeath]

can I suggest this instead? https://stackoverflow.com/a/55985185

Yes you can, but there is no reliable way to do it - there are always a chance the user password to comply with the checks, but not to be base64 encoded. You can do it with 'try except', you can use even validate parameter.... Will ask a colleague which works with that. Currently you can make a new function returning true if it is base64 and false if not. And then we will change only this function. And for beginning you can put whatever check you would like. Will update you these days is it possible to really check this.

[neothematrix]

cool, but I now see the point, the base64 decode bit was already on loblab's code, I've never inherited it so I guess it makes sense to accept the merge and have a fully compatible fork for anyone to use.

[Angel0ffDeath]

cool, but I now see the point, the base64 decode bit was already on loblab's code, I've never inherited it so I guess it makes sense to accept the merge and have a fully compatible fork for anyone to use.

Probably you started with some other fork...or branch... it doesnt matter. So now in all cases password will be base64 encoded and we dont need to think about that. Just dont forget to encode your pass in script you are using :-)

[neothematrix]

Probably you started with some other fork...or branch... it doesnt matter. So now in all cases password will be base64 encoded and we dont need to think about that. Just dont forget to encode your pass in script you are using :-)

exactly, I forked at some point, hopefully I didn't leave out anything else. I've just updated my scripts to use the base64 encoded password instead and just to confirm the exception, my base64 password doesn't end with "=" :-D

[Angel0ffDeath]

Probably you started with some other fork...or branch... it doesnt matter. So now in all cases password will be base64 encoded and we dont need to think about that. Just dont forget to encode your pass in script you are using :-)

exactly, I forked at some point, hopefully I didn't leave out anything else. I've just updated my scripts to use the base64 encoded password instead and just to confirm the exception, my base64 password doesn't end with "=" :-D

I reviewed your last merge in the code. Now more or less it looks like mine :-) :-) :-) Which is good.

[Angel0ffDeath]

just

@neothematrix Ending of pass with '=' is just filling - 64base encoded string should have length multiple of 4 and of course this depends on initial string, so '=' is added to the end to adjust the length, which means you can have between zero and three '=' at the end of base 64 encoded string... Nevertheless - after last merge this problem is over. You just need to update now readme.md file to be consistent with the fork, and we will continue to improve the soft :-)

[neothematrix]

and now we also have an updated README file!