I need to retrieve my saved reading list from my Pocket account
and it seems that I need to acquire access token through their oAuth to make a request.
I've got consumer key for the access token and as per Pocket API documentation, the request will resemble something like this.
POST /v3/oauth/request HTTP/1.1
Host: getpocket.com
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Accept: application/x-www-form-urlencoded
consumer_key=1234-abcd1234abcd1234abcd1234&
redirect_uri=pocketapp1234:authorizationFinished
My question is... isn't oAuth for 3rd party apps to enable authentication via Google, Facebook account? I don't see how this idea is relevant for my website that will only require access to my own data from Pocket to share on my site.
I understand I will need to authenticate somehow so I can access my data but is oAuth the process I will need to go through to get what I need?
It seems that they support only 3 legged OAuth flow. You can use Grant in your NodeJS app, or just get access token from here.
Grant
save the following example to a file
set your key here: key:'...'
install the needed dependencies
run the file with node.js
navigate to http://localhost:3000/connect/getpocket
follow the instructions on screen
At the end you'll see your access_token.
var express = require('express')
, session = require('express-session')
var options = {
server: {protocol:'http', host:'localhost:3000'},
getpocket: {key:'...', callback:'/getpocket_callback'}
}
var Grant = require('grant-express')
, grant = new Grant(options)
var app = express()
app.use(session({secret:'very secret'}))
app.use(grant)
app.get('/getpocket_callback', function (req, res) {
console.log(req.query)
res.end(JSON.stringify(req.query, null, 2))
})
app.listen(3000, function () {
console.log('Express server listening on port ' + 3000)
})
}
Purest
Then you can use Purest to make requests to the Pocket's REST API.
var getpocket = new Purest({provider: 'getpocket'})
getpocket.query()
.post('get')
.auth('[API_KEY]', '[ACCESS_TOKEN]')
.request(function (err, res, body) {
// body is the parsed JSON response
})
For anyone reading this in 2021 or later, wanting to make a simple script to add articles to their pocket, I came up with this:
1: get your consumer key, via pocket's site.
2: get you access token, using this tool it's very simple. If you want to make an app or something that'll work without it, I guess the above (old) answer might work, didn't test it.
3: Use the following code to add an article:
var request = require('request');
request.post({
url: 'https://getpocket.com/v3/add',
form: {
url: 'https://articleToAdd.com',
consumer_key: '123456-12abcd1234a1ab12a12abc12',
access_token: '12345a1a-1ab1-1a12-12a1-1a1234'
}
},
function(err, httpResponse, body) { console.log(httpResponse.body) }
)
Hope it helps someone that is looking to do the same. Retrieving/modifying articles is similar, look here for the specifics.
Related
I'm try to create a Web Service that connects to the Google Calendar API. In attempting to authorize my app, I have generated a url with necessary scopes. The problem is when I try to redirect the client to the generated url, I am getting a 405 error with the following message:
Response to preflight request doesn't pass access control check: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost:8080' is therefore not allowed
access. The response had HTTP status code 405.
For the most part I have been following this guide: https://developers.google.com/identity/protocols/OAuth2WebServer using the node.js client library.
From what I understand, it seems that Google has not configured their server to accept cross origin requests, what I don't understand is how I am supposed to redirect my users to their authorization page if I cannot send a request from my domain.
Here's the relevant code:
export function authorize(req, res, callback): any {
let auth = new googleAuth();
let oauth2Client = new auth.OAuth2(clientId, clientSecret, redirectUrl);
if (// Check if we have previously stored a token.) {
oauth2Client.credentials = //get token;
callback(oauth2Client);
} else {
//redirect to google authentication page
let authUrl = oauth2Client.generateAuthUrl({
access_type: 'offline',
state: '/',
scope: SCOPES
});
res.redirect(authUrl);
}
}
Turns out when AJAX receives a 300 status code, the browser will automatically send another GET request to the returned location on behalf of the client. Even if I had gotten around my CORS issue I would have then had to manually load the html page myself since the request was made on behalf of the client. What I really want is for the browser to make the request to the auth uri.
So my solution to this problem is to detect redirects on the front end and have the browser issue a completely new GET request. Still seems like a work around so if anyone else has a better solution I'd like to hear it.
If some one use React or similar SPA Framework to solve this problem related to OAuth 2 read this:
Do not redirect on the server side. Don not do this (node.js/express as backend example):
router.get('/go', errorHandler(async (req, res, next) => {
res.redirect(authenticationUrl);
})
);
DO THIS:
router.get('/go', errorHandler(async (req, res, next) => {
res.json({
redirectUrl: 'https://google.com'
})
})
);
And then on your frontend client, get the response and make redirect. Example:
getUrl = async () => {
try {
const res = await API.get(`/go`);
window.location = res.data.redirectUrl;
} catch (err) {
console.log(err);
}
}
Work in React. Checked!
As per the flow, it is shown like Browser (APP) -> API (Server) -> Google auth (redirection), It is a very common trail with Identity provider servers like AWS, Google Auth, etc.. as they never send an additional header of ALLOW ORIGIN that's why browser reject the request when it comes to the point of redirection
Now comes the workout solution.
The App domain (http://localhost:3000) should be added as a trusted domain at the IDP server
Request to API server for Auth initiation should be
window.location.href = 'http://localhost:5000/api/v1/auth/login-google';
I have a startup module in angularjs. This module is just to login and have public information (login, prices, newsletter...). I have many roles and for each role, i have an app (angular module). I made this architecture because i have complex module for each role and it was impossible to put all roles in one module.
So, for login, i use jsonwebtoken in node like this :
var token = jwt.sign(user, config.secureToken, { expiresInMinutes: 20*5});
res.json({ token: token, user: user });
It works perfectly. I can login into my app. After that, i have to propose a list of roles to redirect to the right module.
In angular, I have AuthHttp service that adds security headers (with token) to call rest service with $http.
How can i redirect to 'mydomain:port/anotherModule' with $location or $http ?
With this code in nodejs :
app.get('/secondModule', expressJwt({secret: config.secureToken}), function (req, res) {
res.render('restricted/secondModule/index.html');
});
NodeJs sends an html code in response and does'nt redirect...
And if i do this in my angular controller :
location.href = route;
i have this result on nodejs console :
Error: No Authorization header was found
I am not sure about the libraries you are using, but issue seems that you are loosing the token because you navigate to a altogether new page.
Based on your auth library you need to pass the token that you get after auth from one page to another.
The options here are to either use browser sessionStorage or querystring to pass the token along and at it back to the http header collection on the new page (module)
This is an old post but I recently took a long time to figure this out. I may be wrong but I believe nodeJS/expressJS can't read the token from the session storage. I believe you will need to pass the token via the request header using AngularJS.
This depends on the front end that you are using. For me, I am using AngularJS and I have to do something like this.
angular.module('AngularApp').factory('authFactory',
function($window){ //the window object will be able to access the token
var auth = {};
auth.saveToken = function(token){
$window.localStorage['token_name'] = token; //saving the token
}
auth.getToken = function(){
return $window.localStorage['token_name']; //retrieving the token
}
return auth;
}
.service('authInterceptor, function(authFactory){
return { headers: {Authorization: 'Bearer "+ authFactory.getToken()}
} //the last line gets the retrieved token and put it in req.header
Then, you just need to include 'authInterceptor' in all the http methods when you communicate with the backend. This way, nodeJS will be able to pick up the token.
You can see the Authorization field in req.header if you use the chrome developer tool and look at the Network tab. Hope this helps.
I've red this tutorial: http://howtonode.org/socket-io-auth.
It shows how to authenticate users using express and socket.io.
But is there a way to authenticate users using only socket.io without the need for express?
edit:
For session handling I use RedisStore (https://github.com/LearnBoost/Socket.IO/wiki/Configuring-Socket.IO).
Whats left is a module to create authentication cookies.
Does anyone know of a socket.io implementation I can use to create an authentication cookie like you can do with session handling?
I know this is bit old, but for future readers in addition to the approach of parsing cookie and retrieving the session from the storage (eg. passport.socketio ) you might also consider a token based approach.
In this example I use JSON Web Tokens which are pretty standard. You have to give to the client page the token, in this example imagine an authentication endpoint that returns JWT:
var jwt = require('jsonwebtoken');
// other requires
app.post('/login', function (req, res) {
// TODO: validate the actual user user
var profile = {
first_name: 'John',
last_name: 'Doe',
email: 'john#doe.com',
id: 123
};
// we are sending the profile in the token
var token = jwt.sign(profile, jwtSecret, { expiresInMinutes: 60*5 });
res.json({token: token});
});
Now, your socket.io server can be configured as follows:
var socketioJwt = require('socketio-jwt');
var sio = socketIo.listen(server);
sio.set('authorization', socketioJwt.authorize({
secret: jwtSecret,
handshake: true
}));
sio.sockets
.on('connection', function (socket) {
console.log(socket.handshake.decoded_token.email, 'has joined');
//socket.on('event');
});
The socket.io-jwt middleware expects the token in a query string, so from the client you only have to attach it when connecting:
var socket = io.connect('', {
query: 'token=' + token
});
I wrote a more detailed explanation about this method and cookies here.
Instead or wiring up authentication and session handling code manually, I'd recommend to go with a dedicated module, such as session.socket.io (but please note that this is a module that requires Express as well).
I guess (but don't know) that there were downvotes because you need some sort of session handling, and you most probably do not want to do this manually as well ;-). Hence it's a quite good idea to stick with Express here.
Nevertheless, it's an interesting question, although I can not answer on how to do it without Express.
I am quite new to node.js, just started a few days ago. and i only can answer to the first part to the question, which is user authentication without the use of express. and i also got no session-style handling yet.
the reason I am still answering to this question is to help out other people who are new to node with a more simple alternative solution for the beginning.
the solution i am currently using in my learning project (a socket.io - based chat, what else?) is using the http server for authentication.
if you can't get a valid authentication on the http server, you'll never get access to the page with the socket.io interface.
the user authentication on the http server is handled by reading out some POST data. only if the POST data is valid user data the user is allowed to move on to the chat where the socket.io interface is.
I'm building a client application in Node.js for creating new JIRA issues and I want to authenticate users using OAuth. The Atlassian docs are pretty bad for Jira and Oauth newcomers. So, I'm looking for a single example that describes exactly how to set up the JIRA application link, and the how to build a basic app in node that connects to Jira via OAuth. I'm not sure where else to look. (I'm using JIRA v6.0.4)
There is an example for Node.JS with OAuth in the Atlassian repo that Brian also mentioned. I think it is for the 2-legged authentication.
It needs a pre-negotiated consumer key already set up by you. Here is an example how to obtain a token you can save in your config file: https://developer.atlassian.com/jiradev/api-reference/jira-rest-apis/jira-rest-api-tutorials/jira-rest-api-example-oauth-authentication
Here's a blog describing node.js and jira authentication using Oauth
It is in an express framework. I paste some part of the code below.
var base_url = "YOUR_JIRA_BASE_URL"; //example https://test.atlassian.net
app.get('/jira', function(req, res) {
var oa = new OAuth(base_url + "/plugins/servlet/oauth/request-token", //request token
base_url + "/plugins/servlet/oauth/access-token", //access token
"mykey", //consumer key
"YOUR_PEM_FILE_CONTENT", //consumer secret, eg. fs.readFileSync('jira.pem', 'utf8')
'1.0', //OAuth version
"http://localhost:1337/jira/callback", //callback url
"RSA-SHA1");
oa.getOAuthRequestToken(function(error, oauthToken, oauthTokenSecret) {
if (error) {
console.log(error.data);
response.send('Error getting OAuth access token');
} else {
req.session.oa = oa;
req.session.oauth_token = oauthToken;
req.session.oauth_token_secret = oauthTokenSecret;
return res.redirect(base_url + "/plugins/servlet/oauth/authorize?oauth_token=" + oauthToken);
}
});
});
If anyone is confused about any part of the code, you can add comment to this answer.
I start planning a REST API with node.js ,express and mongodb. The API provides data for a website (public and private area) and maybe later a mobile app. The frontend will be developed with AngularJS.
For some days I read a lot about securing REST APIs, but I don’t get to a final solution. As far as I understand is to use HTTPS to provide a basic security. But how I can protect the API in that use cases:
Only visitors/users of the website/app are allowed to get data for the public area of the website/app
Only authenticated and authorized users are allowed to get data for private area (and only data, where the user granted permissions)
At the moment I think about to only allow users with a active session to use the API. To authorize the users I will use passport and for permission I need to implement something for myself. All on the top of HTTPS.
Can somebody provide some best practice or experiences? Is there a lack in my “architecture”?
I've had the same problem you describe. The web site I'm building can be accessed from a mobile phone and from the browser so I need an api to allow users to signup, login and do some specific tasks. Furthermore, I need to support scalability, the same code running on different processes/machines.
Because users can CREATE resources (aka POST/PUT actions) you need to secure your api. You can use oauth or you can build your own solution but keep in mind that all the solutions can be broken if the password it's really easy to discover. The basic idea is to authenticate users using the username, password and a token, aka the apitoken. This apitoken can be generated using node-uuid and the password can be hashed using pbkdf2
Then, you need to save the session somewhere. If you save it in memory in a plain object, if you kill the server and reboot it again the session will be destroyed. Also, this is not scalable. If you use haproxy to load balance between machines or if you simply use workers, this session state will be stored in a single process so if the same user is redirected to another process/machine it will need to authenticate again. Therefore you need to store the session in a common place. This is typically done using redis.
When the user is authenticated (username+password+apitoken) generate another token for the session, aka accesstoken. Again, with node-uuid. Send to the user the accesstoken and the userid. The userid (key) and the accesstoken (value) are stored in redis with and expire time, e.g. 1h.
Now, every time the user does any operation using the rest api it will need to send the userid and the accesstoken.
If you allow the users to signup using the rest api, you'll need to create an admin account with an admin apitoken and store them in the mobile app (encrypt username+password+apitoken) because new users won't have an apitoken when they sign up.
The web also uses this api but you don't need to use apitokens. You can use express with a redis store or use the same technique described above but bypassing the apitoken check and returning to the user the userid+accesstoken in a cookie.
If you have private areas compare the username with the allowed users when they authenticate. You can also apply roles to the users.
Summary:
An alternative without apitoken would be to use HTTPS and to send the username and password in the Authorization header and cache the username in redis.
I would like to contribute this code as an structural solution for the question posed, according (I hope so) to the accepted answer. (You can very easily customize it).
// ------------------------------------------------------
// server.js
// .......................................................
// requires
var fs = require('fs');
var express = require('express');
var myBusinessLogic = require('../businessLogic/businessLogic.js');
// .......................................................
// security options
/*
1. Generate a self-signed certificate-key pair
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out certificate.pem
2. Import them to a keystore (some programs use a keystore)
keytool -importcert -file certificate.pem -keystore my.keystore
*/
var securityOptions = {
key: fs.readFileSync('key.pem'),
cert: fs.readFileSync('certificate.pem'),
requestCert: true
};
// .......................................................
// create the secure server (HTTPS)
var app = express();
var secureServer = require('https').createServer(securityOptions, app);
// ------------------------------------------------------
// helper functions for auth
// .............................................
// true if req == GET /login
function isGETLogin (req) {
if (req.path != "/login") { return false; }
if ( req.method != "GET" ) { return false; }
return true;
} // ()
// .............................................
// your auth policy here:
// true if req does have permissions
// (you may check here permissions and roles
// allowed to access the REST action depending
// on the URI being accessed)
function reqHasPermission (req) {
// decode req.accessToken, extract
// supposed fields there: userId:roleId:expiryTime
// and check them
// for the moment we do a very rigorous check
if (req.headers.accessToken != "you-are-welcome") {
return false;
}
return true;
} // ()
// ------------------------------------------------------
// install a function to transparently perform the auth check
// of incoming request, BEFORE they are actually invoked
app.use (function(req, res, next) {
if (! isGETLogin (req) ) {
if (! reqHasPermission (req) ){
res.writeHead(401); // unauthorized
res.end();
return; // don't call next()
}
} else {
console.log (" * is a login request ");
}
next(); // continue processing the request
});
// ------------------------------------------------------
// copy everything in the req body to req.body
app.use (function(req, res, next) {
var data='';
req.setEncoding('utf8');
req.on('data', function(chunk) {
data += chunk;
});
req.on('end', function() {
req.body = data;
next();
});
});
// ------------------------------------------------------
// REST requests
// ------------------------------------------------------
// .......................................................
// authenticating method
// GET /login?user=xxx&password=yyy
app.get('/login', function(req, res){
var user = req.query.user;
var password = req.query.password;
// rigorous auth check of user-passwrod
if (user != "foobar" || password != "1234") {
res.writeHead(403); // forbidden
} else {
// OK: create an access token with fields user, role and expiry time, hash it
// and put it on a response header field
res.setHeader ('accessToken', "you-are-welcome");
res.writeHead(200);
}
res.end();
});
// .......................................................
// "regular" methods (just an example)
// newBook()
// PUT /book
app.put('/book', function (req,res){
var bookData = JSON.parse (req.body);
myBusinessLogic.newBook(bookData, function (err) {
if (err) {
res.writeHead(409);
res.end();
return;
}
// no error:
res.writeHead(200);
res.end();
});
});
// .......................................................
// "main()"
secureServer.listen (8081);
This server can be tested with curl:
echo "---- first: do login "
curl -v "https://localhost:8081/login?user=foobar&password=1234" --cacert certificate.pem
# now, in a real case, you should copy the accessToken received before, in the following request
echo "---- new book"
curl -X POST -d '{"id": "12341324", "author": "Herman Melville", "title": "Moby-Dick"}' "https://localhost:8081/book" --cacert certificate.pem --header "accessToken: you-are-welcome"
I just finished a sample app that does this in a pretty basic, but clear way. It uses mongoose with mongodb to store users and passport for auth management.
https://github.com/Khelldar/Angular-Express-Train-Seed
There are many questions about REST auth patterns here on SO. These are the most relevant for your question:
Securing my Node.js app's REST API?
RESTful Authentication
Basically you need to choose between using API keys (least secure as the key may be discovered by an unauthorized user), an app key and token combo (medium), or a full OAuth implementation (most secure).
If you want to secure your application, then you should definitely start by using HTTPS instead of HTTP, this ensures a creating secure channel between you & the users that will prevent sniffing the data sent back & forth to the users & will help keep the data exchanged confidential.
You can use JWTs (JSON Web Tokens) to secure RESTful APIs, this has many benefits when compared to the server-side sessions, the benefits are mainly:
1- More scalable, as your API servers will not have to maintain sessions for each user (which can be a big burden when you have many sessions)
2- JWTs are self contained & have the claims which define the user role for example & what he can access & issued at date & expiry date (after which JWT won't be valid)
3- Easier to handle across load-balancers & if you have multiple API servers as you won't have to share session data nor configure server to route the session to same server, whenever a request with a JWT hit any server it can be authenticated & authorized
4- Less pressure on your DB as well as you won't have to constantly store & retrieve session id & data for each request
5- The JWTs can't be tampered with if you use a strong key to sign the JWT, so you can trust the claims in the JWT that is sent with the request without having to check the user session & whether he is authorized or not, you can just check the JWT & then you are all set to know who & what this user can do.
Many libraries provide easy ways to create & validate JWTs in most programming languages, for example: in node.js one of the most popular is jsonwebtoken
Since REST APIs generally aims to keep the server stateless, so JWTs are more compatible with that concept as each request is sent with Authorization token that is self contained (JWT) without the server having to keep track of user session compared to sessions which make the server stateful so that it remembers the user & his role, however, sessions are also widely used & have their pros, which you can search for if you want.
One important thing to note is that you have to securely deliver the JWT to the client using HTTPS & save it in a secure place (for example in local storage).
You can learn more about JWTs from this link
If you want to have a completely locked down area of your webapplication which can only be accessed by administrators from your company, then SSL authorization maybe for you. It will insure that no one can make a connection to the server instance unless they have an authorized certificate installed in their browser. Last week I wrote an article on how to setup the server: Article
This is one of the most secure setups you will find as there are no username/passwords involved so no one can gain access unless one of your users hands the key files to a potential hacker.