Hi. With your sample files, I have configured the apikey with the Redirect URI, run the sample, click the "Get Access Token" button, a login appears, grant access to the application name defined in the apikey, click in "Grant Access".
Tracking the HTML source code for this 'grant access' page, this contains data that seems to be ok, for example:
<input name="preregistered_redirect_uri" value="http://www.myserver.com/socialn2/test/ccontact_sdk/examples/getAccessToken.php" type="hidden"/>
This is the same link for the published page where the process started. Is the same Redirect URI configured in the apikey.
So it seems to be ok, but this page displays an error "Error: redirect_uri_mismatch: Redirect URI mismatch" when the next code is reached:
$accessToken = $oauth->getAccessToken($_GET['code']);
The link already contains a code, so it should work.
Could you explain me what's going on?
I'm in the same boat here. Trying to develop a module for the WHMCS billing system. I'd like to provide this addon module to others who use WHMCS, but it seems that I can't use the key to redirect other users of this addon module to their own website.
This is pretty much a show stopper for enabling me to share this module with others, unless I make then generate their own key. To say I'm disappointed is an understatement. I am frustrated by this. What a horrible limitation in this API. Even more frustrating is that this looks like it's been the case for several years.
It seems there is no workaround to this, so I'm not asking for the answer. Just expressing my deep disappointment and hoping that perhaps the API can be tweaked to allow this type of developing and sharing of code.
Thank you for your feedback on this and for sharing your experience with us. In this case, it is not likely that this will change, as the limitation that a redirect URI must always match is part of the OAuth 2.0 specification that we are implementing for authentication. Because this is a core part of the OAuth implementation, it is not likely that it will be changed. One aspect of that limitation is that this leaves using a central agent that can pass that redirect on to the correct user as the only option to implement this properly.