I have a Meteor web deployed with Phusion Passenger integrated with Apache. The users access it with http://mycompany.org:3001.
That Meteor web communicates, via REST API, with another external server.
That external server has 3 versions of the same REST API:
http://external_server/v1/restapi
http://external_server/v2/restapi
http://external_server/v3/restapi
Each version of the above REST API manages a different user database, i.e. user_DB_1 -> v1, user_DB_2 -> v2, user_DB_3 -> v3.
Currently, my deployed Meteor web is making calls to the v1 of that REST API (http://external_server/v1/restapi).
Now, I have to call the other versions of the REST API (v2 and v3) with the same Meteor web, like this:
http://mycompany.org:3001/meteor_web_v1 (currently http://mycompany.org:3001)
http://mycompany.org:3001/meteor_web_v2
http://mycompany.org:3001/meteor_web_v3
Is it possible to capture the version of that URL and pass it as parameter to the Meteor web so that it calls the corresponding API?
For example, if the user make HTTP requests to http://mycompany.org/meteor_web_v1/login, then the web calls to http://external_server/v1/restapi, and so on...
Which is the approach here? Using maybe Apache mod_rewrite, Iron Router or which solution?
You can use either flow router or iron router to give you the url part as a parameter, you name it like this in your route declaration:
'/:myroute'
and then you will get a route parameter as a variable which you can use in your code to pass to your server method to do the http request.
You are doing the http request from the server, right ? Doing it that way prevents any CORS problems, and offloads the waiting to the server. The server should then update the database wth the received data, and the client will auto-refresh to make the results available.
Related
Salutations!
I have just completed my first REST API, deployed on heroku, and I decided it would be cool to make $0 a month through rapidAPI.
The rapidAPI testing dashboard passes the tests successfully - with one of their keys being a requirement for an API call.
However when I access the site on a browser or on Postman, there is no need for an API key and therefore no restrictions in get requests.
I have noticed that the test code makes a fetch request to the rapidAPI url for the project but how can I make the heroku url accessible only from rapidAPI?
I know it's extremely unlikely someone will find my heroku app url but it is technically possible.
I appreciate your time and insights.
RapidAPI provides 2 security features to support this:
set X-RapidAPI-Proxy-Secretin the API Dashboard: this token is added in the X-RapidAPI-Proxy-Secret HTTP header for each request. You should validate this for every API call. This is the default measure in place.
the list of IP addresses used by RapidAPI is provided: you can check/validate for every API call.
There might be Heroku Addon to help with the IP filtering, but those are typically enterprise-plugin (with associated cost).
RapidAPI allows you to add secret headers and/or query string parameters to API requests. The RapidAPI proxy adds these secrets to every request, but are hidden from the API consumers.
Find more details in this page: https://docs.rapidapi.com/docs/secret-headers-parameters
I wonder what is the difference between REST Client like Postman and browser? I want to make API calls but I dont understand why I have to use a REST Client instead of a browser.
A browser permits to create simple GET calls, you invoke a url and obtain the response.
A REST Client permits more possibilities like:
to construct every type of REST/HTTP call such as POST,PUT and DELETE,
add headers to the calls,
build a body for the calls (a json/xml or whatever of want one).
It's a tool more sophisticated.
You can install a standalone one like:
Postman
Insomnia
or install a browser extension for Firefox and Chrome like:
Resting
Rester
Disclaimer: I'm the creator and maintainer of Resting
I'm writing an express/node/angular application. When the client-side angular controllers need some data, they request it from the server using an endpoint that returns JSON.
This endpoint is behind some passport.authenticate('local') middleware, however this endpoint is exactly what we need for a public API.
Our API uses a passport.authenticate('basic') (basic http auth).
I'm trying to find a way to use the same URL for both, but I don't want users to my site who aren't logged in to see an http authentication window. I somehow need to tell "is this an API request, or an xhr request from the site"
For example, I want the following URL to work for a locally-authenticated user (would have been authenticated via a /login route) or for an API user:
app.get('/api/v1/tasks', passport.authenticate('basic'), tasks.list);
The only alternative I know of that works is splitting these into two different URLs, one for the site to use internally, and one for the public API. Maybe that's a better strategy for security/organization anyway?
I am trying to access YouTube API using ASP.net MVC 4.
Should I use :
Client ID for web application or Client ID for native application?
I tried both:
Using Client ID for web application will give me this error: The redirect URI in the request: http://localhost:55193/authorize/ did not match a registered redirect URI
Using Client ID for native application will redirect me to this page with a token: http://localhost:55318/authorize/?code=4/ufFRXOfT7GS28wg_eqA9pQ9wVtFN.cgyV3VCJtGkXdJfo-QBMszsijcV9jQI
I am confused of google limited documentation.
If you're building a WebApp, you should use the client ID for web application. The error messages you're seeing indicate that your app is configured to, after authorizing, redirect to the URLs you see there, but you haven't set, in the console, the permissions to let those URLs handle callbacks.
Visit the developer console (https://console.developers.google.com/) and find your project, then choose the "credentials" link under the APIs & Auth section. Look for the client ID that you're using, and edit it; there will be a field to put in your allowed redirect URIs (in other words, the permissible places that your oAuth calls can redirect to after visiting google's auth endpoints).
2 simple questions :
Do all http requests make thru http adapter do go thru the worklight server first?
If so then does it mean even a http adapter request to a public web site say a request to yahoo site for a stock price would also go thru worklight server first then next to the yahoo web site? If so then how do I make a http request without going thru the worklight server? I just want to go straight to yahoo web site without the "intermediate" server (i.e. workligth server)
1) Do all http requests make thru http adapter do go thru the
worklight server first?
Yes. Worklight Adapters work by executing JavaScript on the Worklight Server using Mozilla Rhino. You can read more about Adapters in the IBM Worklight Getting Started Modules. Look at Modules 5 and 6 for Adapter specific details. There are also code samples you can try next. The API documentation is in IBM InfoCenter. There is also a Developer Works article that talks about adapters that you may find helpful.
2) If so then does it mean even a http adapter request to a public web
site say a request to yahoo site for a stock price would also go thru
worklight server first then next to the yahoo web site?
Yes.
I just want to go straight to yahoo web site without the
"intermediate" server (i.e. workligth server)
IBM Worklight ships with jQuery, you can use the ajax method. Here's an example:
WLJQ.ajax( "http://finance.yahoo.com/d/quotes.csv?s=DOW+MSFT+AAPL+GOOG&f=snl1" )
.done(function (data) {
console.log(data);
});
Note that WLJQ is the namespace for the version of jQuery that Worklight ships. You can use jQuery or $ by doing: var $ = WLJQ; or var jQuery = WLJQ;.
You should get something like this back:
"DOW","Dow Chemical Comp",30.89
"MSFT","Microsoft Corpora",27.37
"AAPL","Apple Inc.",448.97
"GOOG","Google Inc.",790.13
If you use the adapter API on the client side then your request with go through the Worklight server. You can still make AJAX requests from the client side and skip the server. Essentially you'd be making server requests in the same way you would in Cordova, which means using a whitelist to allow your requests to access third party servers.
Of course You can access it directly without calling any adapter functions using simple jquery ajax calls.
$.ajax({
url: url,
data: data,
success: success,
dataType: dataType
});
or
$.get(url, function() {
alert( "success" );
})
.done(function() {
alert( "second success" );
})
.fail(function() {
alert( "error" );
})
.always(function() {
alert( "finished" );
});
Do all http requests make thru http adapter do go thru the worklight
server first?
Absolutely not, it is entirely up to you. If you are using HTTP Adapters, then the HTTP request would be initiated from the Worklight Server and it would serve you back the response.
If so then does it mean even a http adapter request to a public web
site say a request to yahoo site for a stock price would also go thru
worklight server first then next to the yahoo web site? If so then how
do I make a http request without going thru the worklight server? I
just want to go straight to yahoo web site without the "intermediate"
server (i.e. workligth server)
If you are using a HTTP Adapter, then it would go through Worklight Server as per the first answer.
If you do not want the intermediate server, then you can use the conventional means of doing the HTTP request as you would do otherwise either through the Javascript /Ajax layer or natively (Android/iOS/Windows..)
Adapters are useful when it comes to security which Worklight uses to make sure that the request is initiated from the registered device - the authentication is done by exchanging device tokens etc.
I think you are missing an important point about the adapter architecture in WL. The adapter lives in the server, so by definition, any request you make with it will "go thru" the server. However, the information is not going through your WAS (or Tomcat) server.
Is there a reason you don't want to use the adapter? I would recommend using it since it makes it easier to pull down data, whether from a RESTful http call or database query.
If you did want to get around the adapter, there are issues with cross-domain authorization. I don't have much experience in this area, but you may be able to get around it using something like jQuery.ajax().