Add GET_CONTENT and INSERT actions.

[ericatkin]

This branch adds support for 3rd party app integration/automation using
standard "otpauth://" URIs
(https://github.com/google/google-authenticator/wiki/Key-Uri-Format).
The GET_CONTENT intent action will return the current code for an
existing token. The INSERT action will install a new token and return
the current code (and the token secret to allow stateless operation by
the intent sender). Both actions are subject to user confirmation.

These two actions will allow a 3rd party app to alleviate the cubersome
and error prone user process of being prompted for an OTP code,
switching to FreeOTP, memorizing or copying the code to the clipboard,
switch back to the original app, and finally entering the code. The 3rd
party app should appropriately handle the exception cases of FreeOTP not
being installed or the user denying the requested action.

[npmccallum]

Please make sure to follow: https://chris.beams.io/posts/git-commit/

[npmccallum]

So, I understand the purpose of the GET_CONTENT action. But I don't understand the purpose of the INSERT action. Third party apps can already create tokens by simply opening the otpauth:// url.

I'd also be open to a patch which migrates all token access through these intents. In this case, we need to verify the sender of the intent. If the sender is FreeOTP, we can allow the fetching of tokens without confirmation.

[ericatkin]

Well, it's been almost a year, but if I recall, I didn't want to break the existing functionality, but I had a couple issues with it. First, it is odd to me that an intent action named VIEW results in changes to the state of the apps data. More importantly, I need it to confirm with the user before adding tokens and provide feedback (in the UI for the user as well as an intent result code for the client app) on the result of the request. Neither of these happened with the existing ACTION_VIEW code so I implemented them under a different intent action name (INSERT is more appropriate IMHO) providing the functionality I was after while maintaining backward compatibility. Thanks for your attention on this.

[npmccallum]

@ericatkin It is strange. But, to my knowledge, VIEW is the intent for capturing URLs that are clicked on. In our case, we want to support clicking on otpauth:// URLs in the browser. So that is why we use VIEW. If we can capture those clicks with INSERT, great! But if not, INSERT is probably redundant.

[ericatkin]

Is it ok to add the confirmation and error reporting to the VIEW code path?

[ericatkin]

Actually, I think that is a use case for keeping both. VIEW for urls clicked in a browser, and INSERT for explicit intent based IPC where we can assume the client app wants feedback.

[npmccallum]

@ericatkin We probably need confirmation on VIEW (we don't have it now). What purpose would INSERT serve (besides merely a logical distinction)?

[ericatkin]

For me, the important thing is that my app needs to know if the token was successfully inserted or not. If we can set the result on the VIEW intent then that will likely work for me and seems it would just be ignored in the case of clicked hyperlink. I would also want to the add the confirmation dialog and alert dialog on errors which breaks backward compatibility. I'd be willing to code that up and test these assumptions if it's something you'll merge, but I don't want to do it if it will go nowhere. What do you think?

[npmccallum]

@joekir Do you see any reason this proposal is a bad idea?