[verisure] Adapted to new authentication process and support for non MFA activated user

[jannegpriv]

[verisure] Adapted to new authentication process and support for non MFA activated user. (#11228)

Signed-off-by: Jan Gustafsson [email protected]

[lolodomo]

This is better to push an update rather than the full PR because now the reviewer has to do again a full review! Lost of time for the reviewer and more time before your work is merged.

[jannegpriv]

Sorry, can you describe exactly what I have done wrong so that I will get it right next time? I've always used the command:

git push --force-with-lease

when pushing changes.

[lolodomo]

Please only oush an update containing the changes you will do to handle my comments.

[lolodomo]

Sorry, can you describe exactly what I have done wrong so that I will get it right next time?

Commit your new changes and just run a git push without forcing anything. Something like that:

git commit
git push origin 11228-verisure

[jannegpriv]

Sorry, can you describe exactly what I have done wrong so that I will get it right next time?

Commit your new changes and just run a git push without forcing anything. Something like that:

git commit
git push origin 11228-verisure

OK, I actually was instructed by another maintainer to use -force-with-lease, but then i will not use force anymore.

[jannegpriv]

The instructions here uses git push --force-with-lease.

[lolodomo]

There are situations where forcing push is adapted or even required but during the review process it is clearly not recommended for the reason I previously explained, that is it forces all reviewers to restart a full review of your PR. I did it in your case because your PR was not too large but I may have forgiven for a big PR.

[lolodomo]

This is almost ok for me.
I only discovered something that you should improve, even if not something directly related to this PR.

[lolodomo]

LGTM

[lolodomo]

Build failed due to timeout.

[jannegpriv]

@lolodomo Thanks for the review. :-)
I got a question regarding catching RunTimeException in VerisureBridgeHandler.java on line 131.
Looking at the code, should the try catch be moved to after the scheduler.execute to be able to catch it if it is thrown by VerisureSession.initialize()?

[lolodomo]

I got a question regarding catching RunTimeException in VerisureBridgeHandler.java on line 131.
Looking at the code, should the try catch be moved to after the scheduler.execute to be able to catch it if it is thrown by VerisureSession.initialize()?

Oh yes, you're right, the try/catch is not at the right level.

[jannegpriv]

I got a question regarding catching RunTimeException in VerisureBridgeHandler.java on line 131.
Looking at the code, should the try catch be moved to after the scheduler.execute to be able to catch it if it is thrown by VerisureSession.initialize()?

Oh yes, you're right, the try/catch is not at the right level.

Should I create a new PR to fix that?
I would be nice to get this fixed to the upcoming 3.2.0 release.

[lolodomo]

Should I create a new PR to fix that?

Yes, please.
I merged this PR to not delay your enhancement and because the build was successful (which is something difficult to get since few days).