Open t0rst opened 6 years ago
@t0rst
x-com-tesobe-obp-ios-starter://callback
cause next exception when we use java.net.URL class for URL validation:
suggest we use java.net.URI then!
@constantine2nd In general on iOS/macOS, the scheme is used to locate a resource: a url gets sent to the system's registered handler for the url scheme, hence if the scheme is https, the default web browser is expected to provide the resource (and the iOS/macOS app doesn't get a look in). When the scheme identifies the app (x-app-id) then OS asks the app to find the resource.
(I'm not a seasoned server-side person, so I keep refering back to this stuff:) RFC 3986, §1.1.3
A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location").
...in that sense its a proper url: tells you what resource ("callback"), and how to get there ("x-app-id") (even if "callback" is just a mechanism to close the communication loop, and its contents are not relevant - is that what you meant by is it a URI?)
Test results:
updateConsumerRedirectUrl
⇒ custom iOS schemes accepted in update call, credentials no longer deactivated, and scheme not rejected during log on process. (→ HelloOBP-iOS is working again)Still to do:
#1
above) (→ blocking simple pay demo app)#3
& #4
above are worth doing - I see that people are getting snagged by this problem and posting on slack #general
@t0rst Could you please provide us exact message for URL's with iOS/macOS schemes still being rejected by consumer-registration
if any.
By the way, any chance you could shorten the unregistered error message as well? == item 4 of Action Requests: in the original issue description above.
TL;DR:
Callback URL registration
CanUpdateConsumerRedirectUrl
entitlement, which is not granted by default; have to ask for it#2_1_0-updateConsumerRedirectUrl
to register the actual callback that will be used (was accepted by API call) → a. OAuth token exchange sequence now fails with "OBP-20009: Invalid consumer credentials" - this is the stage before the callback is checked, hence suggests that the expected credentials have changed or that existing credentials have been marked invalid.iOS/macOS requirements for callbacks
iOS/macOS apps use custom callback schemas that i) uniquely identify the app on the iThing/Mac, and ii) is declared in the app's meta data, so that the system learns of it and then knows to dispatch matching formed URLs to the app. This essentially means deriving from the app ID - typically the app resource definition for its meta info includes a scheme formed by
x-${PRODUCT_BUNDLE_IDENTIFIER:lower}
, hence you will see callbacks likex-com.tesobe.helloobp.ios://callback
; OBPKit handles this for developers.The app id will most likely change at some later point in the development lifecycle, hence there's a need to be able to change the registered callback easily.
This mechanism was working fine until checking for callback registration was tightened up.
Action Requests:
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
)#2_1_0-updateConsumerRedirectUrl
"Sorry, the App requested a redirect to an unregistered URL. (Developer note: re-register your URL with PUT /management/consumers/CONSUMER_ID/consumer/redirect_url)"
(the visible part of the current message is "Sorry, the App requested a redirect to a URL that is not registered. Note to application developers: You can set the redirect URL you will use at consumer registration - or update it with PUT/management/consumers....")