I am trying to add the paypal gateway to spree, but am a bit confused what the different fields mean: server, login, password, signature. are login/password supposed to be those that i use to login to paypal? what about server and signature?
Found some info here:
http://guides.spreecommerce.com/payment_gateways.html
server can either be "test" or "live". Not sure why they have this here (as well as a tickbox) but thats the rule anyway!
The signature you get from paypal, as an API signature. If your using developer.paypal.com its pretty easy to get one. After logging in just click "API Credentials" on the left.
Related
I'm working on creating a REST API and one feature is to allow users to register. The general flow is the following:
The user specifies his email and password using the client application (SPA application) and presses the submit button.
A request to the API is made. The API adds the user to the database, generates a verification token and sends an email to the user.
The user verifies his email and clicks a confirmation link.
The API marks the user account as verified.
My question is regarding the confirmation link.
Should the link point to the client SPA application? In this case, the client application will make a POST request to the API with the verification token and the user email.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Another approach would be for the link to go to an endpoint defined by the API. In this case a GET request will be made with the user email and verification token and the API will set the account as verified and inform the user that his account is now active.
I have read that this approach doesn't conform to the REST principles because a GET request should never change the state of a resource. In this case, the user resource will be modified.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Thanks!
Should the link point to the client SPA application?
If your 'Client SPA application' is the sole frontend for end-users, then yes: it should point there. Some people deploy a separate oauth2 / authentication server but that doesn't sound like it's the case here.
The client application will make a POST request to the API with the verification token and the user email.
The token should be enough. I'd avoid sending email addresses through urls.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Both seem like really valid designs. If you want the API to be completely unaware of the front-end and support a multitude of frontends, it would make sense to me that the client sends their own endpoints. There is a security concern though, you don't want arbitrary clients to register arbitrary urls.
If you're just building a single frontend, I don't see a problem with the API knowing the activation url. It also sounds like it would be easy to change if your requirements change later.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Ultimately it doesn't really matter that much. Neither approach sounds like you're really painting yourself into a corner. Either you have a standard endpoint that uses a javascript HTTP request to activate a user, or you have a separate endpoint that redirects a user after activation. Both will work.
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 working on an iOS application and what I'd like to do is have the app ping one universal Gmail account to check for the most recent email.
I went through the guide from Google at https://developers.google.com/gmail/api/quickstart/ios?ver=swift, but the result did not work. After some googling, it appears that some functionality may have been changed, but they haven't updated their documentation yet.
Is there a way to send credentials via https to Gmail and get email messages back? I have an OAuth key via the Gmail API manager, but when I pass it as "access_token", the response says "Login Required".
AFAIK, an error response "Login Required" can be encountered if you try to list the buckets for a project that do not provide an authorization header.
If we check Users.messages: get, it's noted that it requires authorization.
For this, you may want to check Authorizing Your App with Gmail wherein you will find these basic authorization pattern:
During development, register the application in the Google API Console.
When the app launches, request that the user grant access to data in their Google account.
If the user consents, your application requests and receives credentials to access the Gmail API.
Refresh the credentials (if necessary).
Furthermore, if your application needs to access Google APIs on behalf of the user, you should use server-side flow. Please see Implementing Server-Side Authorization for more information.
Sometime back I was involved in writing a sample application to access email from gmail but using C++ on windows. The code is at https://github.com/Panchatcharam/simple_gmail_api. I was able to successfully get emails.
Let's say that I am operating a JIRA installation and want to provide REST API access with oauth authentication. Is it possible to make that access Read-Only? With the REST API, it is possible to create issues and other data, but I would want to prevent the ability to insert data.
I believe it would be possible to achieve read-only REST access with basic authentication since the REST implementation will honor permissions assigned to the user whose credentials are being used with the API, but I would like to use oath as I understand it to be the recommended authentication method as I would assume it is more secure.
Sorry, I'm not sure to understand everything :
oauth and basic auth will work the same way : the connected user has the same credentials as in JIRA interface.
So you have nothing to do.
Very quickly : The difference between basic and oauth, is :
in basic : your client application shall send the user login and password. So your client app should remember the password.
in oauth : JIRA trust your client application (with SSL certificates). When your application is connecting, it says "user lambda is connecting", without sending the password.
I hope it helps
CORRECTION :
Sorry, I did a little confusion with "trusted application links"
So I correct my answer :
You have in the documentation :
Authorize this token Go to the URL in system out and login into JIRA and approve the access. Afterwards JIRA will say that you
have successfully authorised the access. It mentions a verification
code which we need for the next step.
So, the user shall login itself in jira, in order to accept your token, and the user login is binded
I'm developing web-service, where one users (companies) can receive payments directly from another (company's customers). Currently company need to enter its PayPal username, password and signature to receive payments via express checkout api. Is it normal, that users (companies in my case) will enter their PayPal credentials on remote site or it's secure information? I can't find any information about it. But i found, that some services work in the same way:
http://www.getharvest.com/help/invoices-and-estimates/online-payment-and-gateways/paypal-website-payments-pro
http://support.getresponse.com/faq/how-find-api-login-data-paypal
help.wildapricot.com/display/DOC/PayPal+Payments+Pro
Also i found another way for receiving direct payments - generate button (on the PayPal site or manually), where you need only PayPal email of seller. What the differences between these methods, its advantages and disadvantages?
Yes, they are considered private. Since it grants you access to all API operations, it can also be used to empty your PayPal account.
What I would recommend instead of collecting API credentials, is to use 'third-party permissions'.
This means initially requesting permission from the account holder via a pop-up dialog. Once granted, you'll receive an access token. This access token can then be included in the HTTP header of your API calls to make calls on behalf of the customer.
Your users can either manually grant permissions to you (they'll need to log into their PayPal account and navigate to the right section within their Profile), or, if you want to make it easier, you can implement the 'Permissions API'.
I would suggest taking a look at https://developer.paypal.com/webapps/developer/docs/classic/products/permissions/ for more information.
To get started, sign up for an 'application' with PayPal via https://apps.paypal.com/.
Ensure you request access to the Permissions Service and receive an Application ID.
This will be the AppID for the Live environment. For Sandbox, you can use APP-80W284485P519543T.