Unauthorized Access with Paypal REST API - ruby-on-rails

Everything works fine in a development/localhost environment.
When deploying to heroku, using sandbox/test credentials on a new app, and creating a new payment I am getting
A PayPal::SDK::Core::Exceptions::UnauthorizedAccess occurred in orders#create:
Failed. Response code = 401. Response message = Unauthorized.
Again, everything thing works in a development environment
Should I permit any specific domains (like in Facebook integration)?

If you are running a Rails application on a public server, there is quite a chance that the Rails environment is set to "production".
If you further use the config/initializers/paypal.rb and config/paypal.yml generated by the Paypal API SDK's standard generator, then:
the initializer loads configuration for the current Rails environment, which is "production"
and in the production configuration one important line presumes that you want to run on the live API
So most probably you are attempting to communicate with the live API without knowing it. Changing the line to mode: sandbox should make you happy.

I had this problem and I called Paypal. It was a config problem in my account.
To resolve I went to https://developer.paypal.com, logged in, Then clicked on Dashboard Then on my account (left) The Direct credit cards has a grey x next to it so you have to click the link next to it that reads Enable live credentials Once you do this you have to answer some verification questions then they approve your account then your live and the unauthorized error goes away.

Related

Xamarin google play services login setup

I am trying to hook a Xamarin project up to Google Play Services but keep receiving a SIGN_IN_REQUIRED error when calling Connect. I have read a few posts online but cannot determine what actually causes this error message.
I have setup the a game project and also setup an API with oAuth credentials. I have made sure that the same SHA key is being used in the API credentials and in the application while debugging but I am still not making any progress.
I am currently presuming that this is not a coding problem but rather something to do with the setup of the API services etc but have ran out of things to try at this point.
Firstly, to make sure your network connection is normal, you can run this demo in your network environment.developer.xamarin.com/samples/monodroid/google-services/… Donnot forget to change to clientID in string.xaml.Then , open the firebase console, find this app check the clientID if it is same with your code, and check the SHA-1 hash of your signing certificate.

HTTP 403 Error when deploying ASP.NET App to Azure Web App

I am trying build up a Staging Environment for an ASP.NET MVC Web App, but am stumbling from problem to problem, the last one having been this one: HTTP 500.79 Error / System.UriFormatException when deploying ASP.NET App to Azure Web App
Currently I am getting a HTTP 403 - Forbidden, "You do not have permission to view this directory or page." error when trying to access the page.
Authentication-wise the App uses Azure Active Directory as Authentication Provider, which is working fine in local testing (using a Test-AAD) and in production. The local and productive apps are not using Azure Web Apps. I noticed on the Azure App Service page that there is a possibility to specify authentication right within Azure, but I don't really want / need to use that, as everything is specified within the app resp. configured in the web.config (ClientID, ClientSecret and Tenant). Anyway, when I tried filling in the Authentication on Azure directly it did not work either, so I removed it again.
What happens now is that the redirect to the Login page on login.microsoftonline.com works, and according to the AAD Admin the login attempt is being successful, or at least shows no pecularities. However, when being redirected back to my page, I get a generic 403, without any additional information that could help pin the problem down.
I did check all sorts of logs for further details, and the only pecularity I found is that for some very odd reason, all requests are made to a completely gibberish URL:
Requested URL / specified Reply URL: https:\\skillmanagementtest.azurewebsites.net
Actually requested URL according to logs: https:\\Skillmanagementtest:80
I have absolutely no clue where this URL originates from, however, "Skillmanagementtest" with that capitalization seems to be the name I specified for the Azure Web App:
Screenshot resource group items
The web.config is being transformed properly during the CI/CD pipeline and I double-checked the auth settings there (tenant, clientID, clientSecret), and I am really out of ideas what may be causing this problem.
One hint I found on other problems was to check the IIS logs, but when I attempted accessing the directory these logs were said to be placed in I was rejected access, even though I have owner permissions on the App Service...
UPDATE
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.
Check to ensure that what you have in your web.config and app settings matches what you have in the reply URLs for your app registration in the portal. There may be some reference somewhere where the reply URL does not match.
Are you using the openid sample? https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect
Also ensure that you are logging in with a user who has the right permissions under the tenant and to the app itself. My colleague and I made a short video that includes the right configurations that may be helpful for this use case. https://www.youtube.com/watch?v=MohaxN6fsDs
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.

Facebook OmniAuth throwing parameter app_id required when deployed on Heroku

So, I've been developing my app locally for sometime now and I decided today that I would like to deploy it on Heroku to start getting initial feedback for the app. I went through the guide on Heroku to help deploy my Rails 5 app to heroku.
Deployment was smooth and I was shown my login page. I clicked on Login Via FB and I was returned a white page with the following error response
The parameter app_id is required
Now, my obvious plan of action was to follow the trail, refer SO and hopefully come up with a solution for this. I tried every plausible resource on the web but I still get this error.
I've even updated my APP_ID and APP_SECRET variables on heroku. I've even updated Valid OAuth Redirect URIs section in my fb developer settings with the appropriate Heroku URL.
The funny bit is that everything works smoothly on my localhost but fails on heroku which is strange.
I strongly believe that Facebook would through appropriate errors and that app_id is in fact not being sent to fb. If this is the case, how do I solve this?
If you need code snippets to look at, do ask what might be needed to be looked at and I shall update my post accordingly.
Thank you!
the solution turned out to be a pretty simple one. In my application.yml file I had saved my Facebook vars as facebook_app_id and facebook_secret_key. But in my Heroku config vars I had included them as FACEBOOK_APP_ID and FACEBOOK_SECRET_KEY. I was under the impression keys aren't case sensitive. When I changed them to lowercase for Heroku, it worked.

PayPal not redirecting to the IPN notify_url in an MVC system

I am using IPN to receive payment notifications in an MVC system I'm working on. After verifying certain bits and pieces, I proceed to update the database with the "subscription" and "payment details" for the particular user. I am using "notify_url" to redirect back to the system and initiate the PaymentNotification method. This was working correctly up until a few days ago, when it all of a sudden just stopped working. First I thought that the database was not being updated due to an issue within the method itself, but then I noticed that the PaymentNotification (IPN) method was not being hit at all.
Some notes:
A test from the paypal developer's page seemed to redirect correctly
into the IPN. Calling the link directly from the browser hits the method also, so it seems to be externally accessible.
I am using NGROK to make the localhost look like it's
running from a live domain. It does not work with either HTTP or
HTTPS. I am also testing on a hosted environment, with sandbox configuration, within an HTTP domain, and it is not working either.
I am debugging the hidden values in the validation form, right
before redirecting to Paypal and all the values, including:
notify_url are correctly populated. This was working but suddenly
stopped.
Some questions:
What could be the reason? Why would it work all throughout the development
stages but suddenly stop working? Of course, I can't afford to have
this stop working on the live environment!
Is this perhaps an issue
with the sandbox environment? Is IPN safe for Live systems? Can someone talk from experience?
Or
is there perhaps a better option I can look into?
I read this article, which
discusses verifying/activating the email address of the sandbox
account. Can anyone indicate what that might be? And whether the same
email addresses being used could have been working but suddenly
stopped? Do they need to be real emails? As the ones that I was using (and were also working) are not tied to real paypal accounts.
As suggested in the comment, even just for testing Paypal in Sandbox mode, since September 2016, TLS 1.2 is required for PayPal IPN processing. In my case, changing the Sandbox testing business and personal emails to real / valid emails, solved my issue with regards to testing locally using NGROK as a secure tunnel to Local host. More so, this should not be a problem when I actually use the HTTPS certificate.

Integrating Paypal Login in Rails app not working

I'm trying to integrate Paypal login within my Rails app and I can't make it work.
I was following the guide: http://cristianobetta.com/blog/2013/09/27/integrating-login-with-paypal-into-rails/
I created an application from the paypal developer site, and set the followings:
App return URL (test): http:/ /localhost:3000/auth/paypal/callback
App return URL (live): http:/ /localhost:3000/auth/paypal/callback
and I get the error:
"Relying Party Validation error: redirect_uri provided in the request does not match with the registered redirect_uri. Please check the request."
when I try to visit the URL:
http:/ /localhost:3000/auth/paypal
Interesting enough, I get the same error if I input my application credential in the official Paypal API integration tool:
https://devtools-paypal.com/guide/openid/ruby?interactive=ON&env=sandbox
Any ideas?
Thanks
This has changed a bit since the accepted answer, and will presumably change again soon... but here's how you do this now.
Log into developer.paypal.com
Click on Dashboard (https://developer.paypal.com/developer/applications)
Click your app name under "Rest API Apps"
Scroll to the box at the bottom of the screen labeled "Sandbox (or Live) App Settings
Set the Return URL (Where users will be redirected after test transactions)
Click save
NOTE
This Return URL must exactly match the redirect_uri that you pass in via querystring (so it's confusing as to why you'd need to pass it in in the first place)
GOTCHA
At this point in time, the Return URL can seemingly never be updated. In my recent experience, if you don't type it correctly the first time you save it, you will have to create a new app.
You need to set this value inside of your sandbox application on the developer website.
Log into developer.paypal.com
Click Applications
Under My Rest Apps click your App name
Click Edit next to App redirect URLs
Set the return URLs for live or test
Save
I resolved it by setting both the live and test redirect URLs to the same thing.
Plus, I ensured that I ticked to get Personal Information from the advanced settings panel, also adding URLs for privacy and agreement links.
The portal hung when set to localhost addresses for those links, so possibly PayPal tried to dereference them, so I put in real fake URLs.
I was encountering this issue myself, albeit in a Sinatra rather than Rails app - like you, I was using http://localhost:4567/auth/paypal/callback as the return URL - changing it to http://127.0.0.1:4567/auth/paypal/callback on the PayPal dev portal and accessing my app from 127.0.0.1 rather than localhost fixed it for me.

Resources