You can test this yourself without writing any code, just drop the URL into the browser:
E.g. (my Jive is running on localhost:8080, and my add-on was registered with the URL localhost:9092)
If I go here...
I get this...
I tried a few different variations on the redirect_uri, and it only allows me to proceed is I set the redirect_uri to localhost:9092 (the host/port that the add-on was registered with).
So, I think the answer to your question is no, it won't work. The redirect_uri must use the same host and port number as was listed in the jiveclientconfiguration.json file that was included in the add-on.
Yes, that is the way I'm testing this. I think this is weird since I'm working with other 4 social networks and all of them admit the use of sub-domains. Thanks
Unfortunately the domain in redirect_uri domain has to be an exact match, you can still vary in what you provide for query param.
Here is the relevant part from the specification:
The authorization server SHOULD require the client to provide the
complete redirection URI (the client MAY use the "state" request
parameter to achieve per-request customization). If requiring the
registration of the complete redirection URI is not possible, the
authorization server SHOULD require the registration of the URI
scheme, authority, and path (allowing the client to dynamically vary
only the query component of the redirection URI when requesting
Would you mind mentioning the names of couple of those social networks? Allowing sub-domains to differ may be a safe thing to do in-terms of security, but I'd like to play with an implementation before considering it for Jive. Thanks.
Thanks to all! Additionally, I added a %26 (&) to the state, so I can receive more than one parameter.
Don't forget to URL encode characters like "&" that are otherwise meaningful . We've also had good results by stringifying a small JSON structure to pass multiple values in the state variable.
As an alternative to trying to use user-specific redirect URIs, consider passing the user-specific context information in the "state" parameter when you request an authorization code. This will get passed along to the redirect URI once the user grants permission, so the single redirect endpoint can do different things for different people.