I want to build something with dribbbble's API.
As I'm reading the API docs I need a HEADER set to my API_KEY.
var token = 'MY TOKEN HERE';
$http({
method: 'GET',
url: 'https://api.dribbble.com/v1/my_user',
headers: {
'Authorization': 'Bearer ' + token
}
}).success(function() { ... });
Its possible to hide the token, preventing users to see my API KEY in page source?
Can someone explain me whats the best practice using API KEYS in $http?
Your best bet is likely going to be to create your own web service and call the dribble api server side. There is simply nothing you can do to secure information like that client side.
It's possible that dribble validates your api requests as a combination of hostname & key so it may not be is significant of an issue as you perceive it to be.
tl;dr - Nothing is secure client side.
There is nothing you can do to completely protect your API key if it's somewhere in your JavaScript. Which is why a lot of third-party services ask you to provide the domain from which you will call their API so that they can validate the key only if it originates from the domain you registered.
The right way to protect your API key is to create a server-side wrapper that will make the request, and call that from JavaScript. And even having the API keys hardcoded in your server-side code is a bad idea - the best practice is to set them as environment variables.
I usually use this method when I need to create custom headers in Angular JS.
At the beginning of a Module using $http I set my headers for get and post like this.
$http.defaults.headers.get = { 'apikeyName' : 'yourkey' }
$http.defaults.headers.post = { 'apikeyName' : 'yourkey' }
These headers will then be send everytime you use $http in that module and you won't need to specify them each time.
Its possible to hide the token, preventing users to see my API KEY in page source? No, your Angular JS is client side so every client can see the key. (see answer above)
Kind regards
Related
I'm new to web development. I'm creating a website. I have to call some webservices inorder to access some db contents.
$http({
method : 'POST',
url : 'http://some_url',
headers : {
'Content-Type' : 'application/json',
'Accept' : 'application/json'
},
data : JSON.stringify(data)
}).then(
function(response) {
$scope.myData = response.data;
}
The above code is written inside the jsp file. but when we inspect the page we can see the url and with the url anyone can access data using postman. I have to avoid that. Some please give any suggestion to improve the security.
You secure the database. Anything sent to the client is available for them to see. You can uglify & minify...but the code is still there.
This question is very, very broad...
The standard way these days is having all database calls made inside a RESTful webservice. The front-end (usually HTML+JavaScript) will make REST requests to it.
Then, if you need to secure one (or all) requests, provide an authentication method. The most common is using JWT tokens.
In short, I have a Pharbicator setup on a domain A, but then I have to implement a service on domain B which relies on the Pharbicator.
So this is the story, I am trying to gather information using the Phabricator Conduit user.whoami API to see whether the current user is logged in. But due to various reasons I couldn't make it. I would like to know what is the correct way of doing so.
I have tried three methods but they all did not work. Here is what I tried
Method 1: Using Ajax Request
What I did is just to fire an POST Ajax request with the api token
$.ajax({
url: 'http://127.0.0.1:8080/api/user.whoami',
method: 'POST',
cache: false,
data: 'api-token='+app.PHABRICATOR_APIKEY
}).done(function(response) {
console.dir(response);
}).fail(function(jqXHR, textStatus) {
console.log(textStatus);
});
This method does not work (as expected) because it is a CORS request, and the Phabricator server does not have Access-Control-Allow-Origin header.
Although I can add that Access-Control-Allow-Origin header, but somehow this requires modifying the Phabricator source code so I would consider this as the last solution I would do.
Method 2: Using a PHP as proxy and inside use curl to request for it. So the whole request will be like Client Browser <-> PHP Proxy Script <-> Phabricator
This method is actually able to send the request and get response. But the information is wrong as it returns only the user of the API key.
If I understand it correctly, the curl is not having my browser session, so there is no way for it to really know who I (the browser client) am in Pharbricator. So I assume then the API will just fallback to use the information of API key and thus return information not I intended.
Method 3: Using the PHP library __phutil_library_init__.php provide by Phabricator
require_once '/var/www/html/phabricator/libphutil/src/__phutil_library_init__.php';
$api_token = PHABRICATOR_APIKEY;
$api_parameters = array();
$client = new ConduitClient('http://127.0.0.1:8080/');
$client->setConduitToken($api_token);
$result = $client->callMethodSynchronous('user.whoami', $api_parameters);
return $result;
Again this is nothing special, just a direct copy of code from the documentation. But again it is returning only the user the API key belongs to. And I think it is just the same as what method 2 is behaving.
I am thinking if I am understand the Conduit API in a wrong way. And more importantly I would like to know how I should implement the whole architecture so that it can gather information using the current browser session. Thank you.
Is there any way to supply key/value parameters of my choice in the headers of a GET request?
Or should I use a POST request for that - even if my request is purely about retrieving information?
Background: I have a RESTful API that requires a key parameter. I want to use this API as the back-end for a JavaScript application on the same domain. However, I don't want users of the web app to be able to see and steal the key parameter, which they would if the key parameter was supplied as a GET parameter.
I think since my site is served over HTTPS, if I put the key parameter in the header, it will be invisible to the web app user, and that gets around my problem.
invisible is probably not possible..
you can do this in Three ways.
Either you use Salt and hash for generating random key using sha256/512 and some random secret key in your app and pass through GET request.
or can use POST request for same.(easiest method).
Use JWT (JSON web tokens). (relatively more secured). Read docs here http://jwt.io/
I have a backbone marionette application that makes REST api calls.
In my model when i make a api call to login i get a session value back and see the cookie being set in the browser
immediately after when i make another call to get the user information that is logged in i receive a different session or cookie value and no user is found. CORS is enabled and options calls are being made.
When i hook up the api to my other applications that were build off non backbone libraries it works fine. Does anyone know how to solve this?
Here is my post
doLogin: function( data ){
this.fetch({
data: JSON.stringify(data),
type: 'POST',
contentType: 'application/json',
error:(function (e) {
alert('error');
})
});
},
It is not clear on this piece of code but looks like your calls are going to different domains (once you mentioned CORS).
If that is really the case, I am afraid session and cookie might be different because they are probably specific only to the domain that your 1st request (doLogin) reached but not the 2nd request (fetch). More info: Sharing cookies across different domains and different applications (classic ASP and ASP.NET)
Another thing to look is if your both servers REALLY support CORS because one part of the setup is client-side and another is server-side (headers). More info on: http://www.html5rocks.com/en/tutorials/cors/
I've just noticed it doesn't matter where I put my Authenticity Token when submitting a request via AJAX. I can either append it to the form as POST data, or put it into the Header.
Is there any difference? Especially regarding security?
Additionally:
I didn't encode the Token in Javascript. Am I exposed to something now?
Thanks in advance.
EDIT:
form.on("sending", function(file, xhr, formData) {
xhr.setRequestHeader('X-CSRF-Token', AUTH_TOKEN);
// formData.append('authenticity_token', AUTH_TOKEN);
});
This is my Javascript adding the token to the Header or (commented out) to the POST data. AUTH_TOKEN is the raw key. I did not encode it in any way.
Part one
There is totally no difference if you pass authenticity token via GET params, POST data or request headers (POST/GET params are virtually the same in Rails).
Let's look at the code (not the best code I've ever seen but...)
def verified_request?
!protect_against_forgery? || request.get? || request.head? ||
form_authenticity_token == params[request_forgery_protection_token] ||
form_authenticity_token == request.headers['X-CSRF-Token']
end
Request if valid if (any of following)
protect_against_forgery? is false
request is GET
request is HEAD
token in params equals one stored in session
token in headers equals one stored in session
I should add that token is generated for every request and stored in session for later inspection (if subsequent request is POST/PUT/PATCH/DELETE)
So as you see both ways of passing authenticity token are valid.
Part two
Is passing raw auth token in AJAX dangerous? No, as much as passing it in a form is totally not dangerous. To explain further I will quote an excellent answer in another SO question
Why this happens: Since the authenticity token is stored in the
session, the client can not know its value. This prevents people from
submitting forms to a rails app without viewing the form within that
app itself. Imagine that you are using service A, you logged into the
service and everything is ok. Now imagine that you went to use service
B, and you saw a picture you like, and pressed on the picture to view
a larger size of it. Now, if some evil code was there at service B, it
might send a request to service A (which you are logged into), and ask
to delete your account, by sending a request to
http://serviceA.com/close_account. This is what is known as CSRF
(Cross Site Request Forgery).
original answer: https://stackoverflow.com/a/1571900/2422778
I still consider this question laziness/lack of patience on your side as all I wrote is very well explained both in Rails Guides and on Stack Overflow. Hope next time you will be more persistent in looking for answers before posting here.
Anyway I am glad I could help.
You can see the difference when you use some tool like https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project or http://www.charlesproxy.com/
That are proxies, which you can turn on locally to fiddle with your HTTP requests and responses.
Very useful for web development.
Good luck.