Has anyone had luck getting Login With PayPal to work with MVC4? I've tried creating an extension of OAuth2Client, as well as a separate extension of OpenIdClient. Both had the same problem, which was also the problem that occurs directly from a browser.
I copy/paste the endpoint URL (with querystring) into the browser, but it always goes directly to the callback URL without displaying any PayPal-hosted login form. I can verify that the endpoint is correct by removing or altering the redirect_uri (which results in a PayPal error page.)
I am logged out of PayPal through the browser before attempting the tests, and I've tested with Chrome and IE9.
Any ideas? Thank you!
Apparently, PayPal OpenId Connect does not support the "openid" scope. This was verified for my application by using the Login With PayPal button creator and seeing "invalid scope" appended to the redirect's querystring.
The solution (remove "openid" from the scope) presents its own conundrum. According to the spec for OpenId, this scope is REQUIRED. According to the documentation for PayPal, this scope should be sent at a minimum. This looks like a problem that will be fixed, but if fixed, will the attribute be required and therefore break my application? Or will they opt to make the attribute optional.
Related
We are trying to support the 'traditional' Account Linking flow as it seems the most general purpose, gives us a chance to surface T&C's, and we thought would be most bedded in.
But testing in the Assistant mobile app for starters, it fails for most users in our Actions app in Dev - After the user sees the Google-driven pop-up in the Assistant app with the "LINK ACCOUNTS" option - They tap that option, and our authorization screen does not appear.
Actions support have had a look at our Account Linking config and can't see any problems.
A couple of test users with newer Android phones DO see our Authorization screen, but the majority do not.
If we test the Authorization URL by pasting into a browser on the same device - It always displays just fine.
What is strange - If we look in our web server logs during the failed cases, the only hits we are seeing are to our 'TOKEN URL', whereas my understanding is a newly linking user should hit our 'Authorization URL' before ever hitting Token.
The successful cases DO hit our Authorization URL first, as expected.
Feel free to pipe up if anyone can answer ANY of the following:
Any ideas what could be causing problems here?
Or ways we might investigate deeper?
Does an app need to be in Alpha testing, or anything like that before Account Linking works?
Is it normal/expected to hit the Token URL for a user that has never successfully linked accounts?
Can anyone confirm what the Token fetch response should be in that case? (Maybe we are not responding in a way that satisfies the other end)
Does anyone have a dummy/HelloWorld Account Linking web end-point we could test against? (Geeze that would be handy for the developer community!)
I don't know exactly what is going on, but there are a couple of hints about what is happening and what avenue to investigate. I'm going to assume you're doing Account Linking with OAuth only. If you are doing a combination of "Google Sign In for Assistant and OAuth", that might change some things. To address some of your questions:
What could cause the Assistant to go to the Token Endpoint instead of the Auth endpoint?
It wouldn't go to the Token Endpoint unless it already had a Token. I could think of a few possible scenarios:
If it was going to Auth, getting a token since it was already authorized, so no window would pop up. (But you indicated it isn't going to that page.)
If the account in question is already authorized to the project via some other means. You can check https://myaccount.google.com/permissions to see if it is already authorized.
If you had tested it with this account previously and it has a token from then. If so, it should be listed at https://myaccount.google.com/permissions. Probably.
If you're not using the account you think you're using on the device in question.
How to investigate this?
Once you double-check some of the more obvious things (using the right account?):
Look at what is being sent to the Token endpoint
Does the token look familiar? Is it the same between calls? Same between different accounts?
Do you log tokens being issued? Can you?
What about the other information sent along with the token such as the client_id and client_secret?
Does it need to be in Alpha?
I'm not sure. Last I checked, it did not. I do think that it no longer works in the simulator, which is annoying, but doesn't require being in Alpha.
It does make it a little more difficult to check, however, since there is no Directory page that can tell you if the account is already linked. You'll need to go to the list of linked apps for the account to remove your app if it is: https://myaccount.google.com/permissions
Is this normal?
I wouldn't think so. It shouldn't hit the Token Endpoint unless it has an auth code or refresh token to exchange. It has to have that code/token from somewhere.
How should you respond?
If you get an auth code or refresh token that is invalid, or any of the other information provided at the token endpoint doesn't match what it should, you must return HTTP error code 400 "Bad Request" and include as the body the JSON
{"error": "invalid_grant"}
This should force it to go through reauth with the user.
Is there a public test server?
Auth0 isn't exactly public, but is free for basic use, and well suited for test purposes.
TL;DR : I am getting a "12600: Authorisation Denied (12600)" error and can't find what that means in Netbanx/Paysafe's documentation.
Background:
I am using the Netbanx credit card services.
The request is built server-side to obtain a url, which is then embedded in an iframe on the application for clients to pay.
It works like a charm in test mode; the iframe displays Netbanx' form, the client enters their info, clicks "Pay", and the payment is authorized. So far so good.
Now, I've moved to live mode. Configurations (account numbers, API key and API secret) are all valid and used on other projects. The payment request is still correctly built, I obtain a url from Netbanx and it correctly displays the payment form. I enter valid credit card information, click pay, and then, boom: failure page, with error 12600: Authorization denied. I cannot find any info related to that error code. Has this occured to anyone? What does this code mean? Any details would be appreciated!
Thanks!
I believe the issue here relates to Paysafe test API credentials being used on the production environment. These credentials do not translate from test > production as a separate set would need to be used for security reasons.
If you believe that you are ready to go live, you can login to the BackOffice "https://login.test.netbanx.com/" and click the "Go Live" button to start the process!
I'm trying to integrate PayPal PayflowPro / PayflowLink within our system, and in testing everything is working as expected. When we switched over to live credentials, we are able to create a secure token, using the live merchant details; but when attempted to redirect to a hosted checkout page, we are receiving a new error, which we haven't seen before.
Error invalid Required Domain
We have searched for hours, with no reference in PayPal's official documentation or the internet. Can someone who has worked with PayPal, explain what this error means?
Willing to give up some rep to figure this out.
Please check your referrer URL, see if it is valid domain.
They generally check if incoming host url is valid or not.
Trying to get login with PayPal into prestashop, all seem to be done corectly accorting to installation guide but getting this error:
Relying Party Validation error: redirect_uri provided in the request
does not match with the registered redirect_uri. Please check the
request.
What is the problem?
There are two modes for any application on Paypal developers website (i.e. Live and Sandbox mode), please confirm that you are using the same API data that you have configured.
Yes, taking all data from live mode of the app.
I'm working on a project and a new Beats Music API library for Clojure, but in my testing I'm finding it difficult to get write access authentication, but read-only user authentication works fine.
In testing my library I set up a HTML page to do the OAuth and get the OAuth code and then feed that code in to my library to fetch the actual authentication token. The first part works flawlessly, the second part has the dreaded "Developer Inactive" error:
URL: /oauth/token
PARAMS: client_secret, client_id, redirect_uri, code, grant_type=authorization_code
METHOD: post (application/x-www-form-urlencoded)
I've double checked my redirect_uri is the same as defined in my app settings and is the url of the HTML page I generated the code with. I even checked with the support folks to double check that my application wasn't throttled or something, but that took too long and I made a second application and had the exact same results. I've looked at other support questions like this and nothing has helped, so unless I'm missing something in my auth request, my only other thought was that my user account is still on it's 14-day trail and maybe that is affecting my auth token in some way?
Any ideas or suggestions would be greatly appreciated.
From https://developer.beatsmusic.com/docs/read/getting_started/Client_Side_Applications
"The scope of an access token using the implicit flow is limited to read only since client side applications cannot keep a secret. You'll need to request the authorization grant flow via the Web Server Authentication for write permissions, such as updating a playlist."
I hope this helps.
As #jsd pointed out in a comment on my question, there was a typo in the url endpoint. The correct endpoint is (which I had in the other function and that's why it was working correctly):
/oauth2/token