Closed illambo closed 3 months ago
I think it would be great for 3.x. The areas of impact doesn't seem like too "impactful", since basically the pipe need to account for multiple configurable origin
strings and rpId
, am I correct?
Right, 2 pipes already present and maybe one to add for add rpId.
Thanks for the integration and release!
No prob. Note that I removed a pipe and al RP checks are done in one single pipe.
Please check these requirements
Description
Studying the integration of the library on Android and iOS we found that although via WebView (both platform) or Android CustomTabs / iOS SFSafariViewController there are no difficulties, it is necessary to carry out a small server side integration to allow the native implementation of the solution on Android and iOS.
The evaluation of this analysis was done with a small poc (actors: android / ios / web / server), in essence, everything translates (in addition to the various configurations of the case for both environments which are not the responsibility of this library) in:
On the implementation side, the areas of impact that I find are:
I looked at a previous "draft" of closed pr #61 which went in that direction, although in my opinion it can be simplified with a simple in_array (match string) to be able to also be used for other possible non-Android scenarios. For example, for Android I would value with the already calculated android:apk-key-hash (e.g. android:apk-key-hash:hlbf0LpDSuQ3UpvvmFAMc1OhrD96549OYYOkGJKxJVs) instead of calculating the relevant fingerprint (see detail on the composition), in order to make everything simpler (avoid recalculations at each request) and not differentiate per os (possibly commands could be provided for os as helpers to generate the appropriate strings).
Although at the current state of the branches it seems to me that this feat is also compatible on 2.x, perhaps it is better to keep 3.x as the basis (I don't seem to see any conflicts but I don't understand the tests part).
Let me know what you think, thanks.