They have told us about the possibility of using webhook in a project in which a certain system needs to notify when an action occurs. At first we had proposed it as a batch that would consult the existence of data, then the webhook issue seemed acceptable to us.
Now, looking for information about webhooks, I can't find the difference between a lifelong rest API and webhooks. What is the difference between them? The system can call both as soon as the event occurs. What functionality would this additional webhook offer to the system calling the REST endpoint directly with the solution to be executed without further ado? Apart from the fact that the webhook must be public
I understand webhook as a publishing system that can be attacked as a POST, but this is precisely what I understand of a POST-type rest endpoint. I intend to create the webhook as a JAVA project, is there any point to take into account when building it that differentiates it from a normal REST endpoint?
Thanks
All the best
A webhook is an API endpoint. What makes it unique is that it is an endpoint in the "client" application.
For example, let's say your application uses a payment processing API. It makes GET and POST requests to that payment processor's API. But payments take time to be approved, so you set up a "payment approved" endpoint on your end and register it with the payment processor. Once the payment is approved, the payment processor will POST to your endpoint and your application reacts accordingly. We call this endpoint a webhook.
Here's the documentation for one such payment provider's webhook system: https://stripe.com/docs/webhooks.
Related
I wants to communicate between different microservices, but the problem that is arising is microservices are secured with jwt token and I am not able to find a way to send a secured call to the other microservice from first microservice. Is there is a way I can communicate with the service method directly because if I make my api open it will be misused.
Or I have to go through api gateway to send every request through api gate way and make a secure communication from there.
It all depends on what are the exact requirements of your project.
Gateway API usually is used to hide the complexity of microservice from external users that usually have 1 endpoint to talk to.
Also the gateway can handle the security and Authenticate the user (which many companies do indeed).
Now when you pass the gateway and your authenticated request reaches the client, usually you already have a user identity on the request (what was put onto the request by the gateway).
So you know that user "John Smith" has triggered the request.
And now if you need to call another microservice you should decide (and again its your decision):
Whether you need an authentication at all there (maybe internal communication doesn't have to be secured between microservices(
If you do need an authentication between microservices, who authenticates the request?
If its a gateway, all authentication logic is there, but you have to make an additional hop for each request that might be costy
Alternatively If its a direct call, each microservice must implement an authenticat logic. Sure, there is stuff like spring security, other languages/ecosystem have similar solutions, but in general this can be difficult to implement.
If you do make an authenticated call from microservice A to microservice B and the flow was originated by user John Smith that triggered a request to service A, you should decide whether the semantics of the call is:
User "John Smith" contacts the service B, or...
Service A contacts Service B on behalf of user John Smith.
This is really important for authorization if you have any kind of permissions system.
In term of technical implementation usually you can add a JWT header to the request with the required token. If the request was already authenticated and you need to generate user identity, you can merely put a couple of headers on the request.
You can have two api gateway:
one exposed outside
and another one for microservices communication within container.
The one which is exposed outside does the validation of tokens and send claims to the microservices where those claims are used for validation of route protection.
Between microservices communication, send claims that you already have with the second gateway. Hope this helps. If you have found any alternative way let us know.
I am planning on hosting my REST API in a VM in a VNET where the only point of entry is via Azure API Management.
I have multiple back ends so the API Management will route to a different backend base url depending on the group the user is in and the backend will also return different data depending on the user making the call.
Since the Azure API Management can handle authorisation, JWT validation and setting headers etc what type of authorisation code should I put in my REST API application?
Should I try to validate the JWT again in my Java code or just parse the headers?
i.e. is it safe to code it as a public API and trust that the headers have been set correctly by API Management?
Or should I make a call to Azure Active Directory from the Spring controller every time to validate that the user does actually exist in the specified group and that the group specified is the one expected for this backend?
If so, how would I do that from Java and how would I inject an offline version when running locally?
Since your API will be inside a VNET it'll be protected as it is. But, there is really no reason to just have it open. The more layers of protection you can add the better your chances to whistand a potential attack.
So see whatever is most convenient to you. You can rely on APIM doing user authentication and authorization and avoid doing that in your backend API. But it would be a good idea to check if call made to your backend API is coming from APIM, and you can do that by sending credentials from APIM. The best option here would be client certificates: https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-mutual-certificates
But you can also send basic credentials: https://learn.microsoft.com/en-us/azure/api-management/api-management-authentication-policies#Basic
I have been doing research for a couple of hours and haven't found any viable examples or information on how I could receive PayPal notifications for payments and process them within a Java Application.
What I want to do is:
Person makes payment.
PayPal sends a notification to the java program, indicating that they had made a payment, with email, usernames, amount, package name/ID, etc.
Java program processes the payment.
Perhaps I am looking at it the wrong way. So far I have found out that I need a webhook listener or some kind of IPN serverlet program that can read the POST messages PayPal sends and redirect them? Can't this be done directly within my java program?
Thank you!
As you've found, you really need to use Webhook (which is newer in PayPal) or IPN. This technologies let you to configure PayPal to send (as POST requests) certain events on a certain URLs. All you need to do in your program is to handle this events (requests) in Serlvet, RestHandler or whatever else.
I know what I am asking is somehow weird. There is a web application (which we don't have access to its source code), and we want to expose a few of its features as web services.
I was thinking to use something like Selenium WebDriver, so I simulate web clicks on the application according to the web service request.
I want to know whether this is a better solution or pattern to do this.
I shall mention that the application is written using Java, Spring MVC (it is not SPA) and Spring Security. And there is a CAS server providing SSO.
There are multiple ways to implement it. In my opinion Selenium/PhantomJS is not the best option as if the web is properly designed, you can interact with it only using the provided HTML or even some API rather than needing all the CSS, and execute the javascript async requests. As your page is not SPA it's quite likely that an "API" already exists in form of GET/POST requests and you might be lucky enough that there's no CSRF protection.
First of all, you need to solve the authentication against the CAS. There are multiple types of authentication in oAuth, but you should get an API token that enables you access to the application. This token should be added in form of HTTP Header or Cookie in every single request. Ideally this token shouldn't expire, otherwise you'll need to implement a re-authentication logic in your app.
Once the authentication part is resolved, you'll need quite a lot of patience, open the target website with the web inspector of your preferred web browser and go to the Network panel and execute the actions that you want to run programmatically. There you'll find your request with all the headers and content and the response.
That's what you need to code. There are plenty of libraries to achieve that in Java. You can have a look at Jsop if you need to parse HTML, but to run plain GET/POST requests, go for RestTemplate (in Spring) or JAX-RS/Jersey 2 Client.
You might consider implementing a cache layer to increase performance if the result of the query is maintained over the time, or you can assume that in, let's say 5 minutes, the response will be the same to the same query.
You can create your app in your favourite language/framework. I'd recommend to start with SpringBoot + MVC + DevTools. That'd contain all you need + Jsoup if you need to parse some HTML. Later on you can add the cache provider if needed.
We do something similar to access web banking on behalf of a user, scrape his account data and obtain a credit score. In most cases, we have managed to reverse-engineer mobile apps and sniff traffic to use undocumented APIs. In others, we have to fall back to web scraping.
You can have two other types of applications to scrape:
Data is essentially the same for any user, like product listings in Amazon
Data is specific to each user, like in a banking app.
In the firs case, you could have your scraper running and populating a local database and use your local data to provide the web service. In the later case, you cannot do that and you need to scrape the site on user's request.
I understand from your explanation that you are in this later case.
When web scraping you can find really difficult web apps:
Some may require you to send data from previous requests to the next
Others render most data on the client with JavaScript
If any of these two is your case, Selenium will make your implementation easier though not performant.
Implementing the first without selenium will require you to do lots of trial an error to get the thing working because you will be simulating the requests and you will need to know what data is expected from the client. Whereas if you use selenium you will be executing the same interactions that you do with the browser and hence sending the expected data.
Implementing the second case requires your scraper to support JavaScript. AFAIK best support is provided by selenium. HtmlUnit claims to provide fair support, and I think JSoup provides no support to JavaScript.
Finally, if your solution takes too much time you can mitigate the problem providing your web service with a notification mechanism, similar to Webhooks or Resthooks:
A client of your web service would make a request for data providing a URI they would like to get notified when the results are ready.
Your service would respond immediatly with an id of the request and start scraping the necessary info in the background.
If you use skinny payload model, when the scraping is done, you store the response in your data store with an id identifying the original request. This response will be exposed as a resource.
You would execute an HTTPPOST on the URI provided by the client. In the body of the request you would add the URI of the response resource.
The client can now GET the response resource and because the request and response have the same id, the client can correlate both.
Selenium isn't a best way to consume webservices. Selenium is preferably an automation tool largely used for testing the applications.
Assuming the services are already developed, the first thing we need to do is authenticate user request.
This can be done by adding a HttpHeader with key as "Authorization" and value as "Basic "+ Base64Encode(username+":"+password)
If the user is valid (Users login credentials match with credentials in server) then generate a unique token, store the token in server by mapping with the user Id and
set the same token in the response header or create a cookie containing token.
By doing this we can avoid validating credentials for the following requests form the same user by just looking for the token in the response header or cookie.
If the services are designed to chcek login every time the "Authorization" header needs to be set in request every time when the request is made.
I think it is a lot of overhead using a webdriver but it depends on what you really want to achieve. With the info you provided I would rather go with a restTemplate implementation sending the appropriate http messages to the existing webapp, wrap it with a nice #service layer and build your web service (rest or soap) on top of it.
The authentication is a matter of configuration, you can pack this in a microservice with #EnableOAuth2Sso and your restTemplate bean, thanks to spring boot, will handle the underlining auth part for you.
May be overkill..... But RPA? http://windowsitpro.com/scripting/review-automation-anywhere-enterprise
So, here's my challenge: I have to build a webservice which handles payments using PayPal... The SOAP way! Since I'm a Node developer I'm very familiar with REST but the challenge is that I have to build it with Java, XML-schemas and SOAP using the Spring-framework.
Now I found this workflow when using REST: https://devtools-paypal.com/guide/pay_paypal/java?interactive=ON&env=sandbox.
That looks easy as pie to me! But what would this workflow look like when using SOAP and how would you implement this. As in: How do you handle redirects and responseURLs? Or is the workflow different?
P.S. I know PayPal has lots and lots of documentation but when it comes to SOAP, I just can't figure out the workflow or how to handle responseURLs..
Thnx in advance!
I'm going to assume you want to implement Express Checkout.
The flow is basically the same, different endpoints, but same steps. You can see the workflow here:
https://developer.paypal.com/docs/classic/express-checkout/ht_ec-singleItemPayment-curl-etc/
Just reference the diagram. Everything below isn't specific to SOAP.
In brief, the flow looks like this:
1: Call SetExpressCheckout to get back a token.
2: Redirect to PayPal using token obtained in step 1.
3. If user accepts checkout then call GetExpressCheckoutDetails to get transaction details.
4. Use Token and PayerID (obtained in step 3) in call to DoExpressCheckoutPayment to capture payment.
Here's a good place to start: https://developer.paypal.com/docs/classic/api/#ec
The first snag I ran into when implementing the SOAP API versus the REST API was that I couldn't find anywhere in the documentation where to find the redirect URL. The REST API will send it back, the SOAP does not. I had to dig through some of the SDK files to find it.
Redirect to here: https://www.sandbox.paypal.com/webscr?cmd=_express-checkout&token=