I'm building a REST backend for an SPA with NodeJS, Restify and PassportJS for authentication. Everything's working except the last step, which is redirecting the client from the backends /login/facebook/callback to the home page of the application.
I've searched online and found lots of answers for ExpressJS but nothing useful for Node-Restify yet. I've managed to pick up a few snippets of code and this is what I'm attempting at the moment:
app.get('/api/v1/login/facebook/cb', passport.authenticate('facebook', { scope: 'email' }), function(req, res) {
req.session.user = req.user._id;
res.header('Location', '/#/home');
res.send();
});
The response is sent but the location header is not included and the client is presented with a white screen. How do I do a proper redirect using the Node-Restify API?
Restify's Response interface now has a redirect method.
As of this writing, there's a test showing how to use it here.
The contents of that test are:
server.get('/1', function (req, res, next) {
res.redirect('https://www.foo.com', next);
});
Many folks who use Restify are more familiar with ExpressJS. It's important to understand that (again, as of this writing) one of the three main public API differences affecting porting of Express plugins is that the res.redirect method in Restify requires you to pass next (or an InternalError is thrown). I've personally ported several modules from Express to Restify and the main API differences at first are (in Restify):
server.use is only for path & HTTP-method-agnostic middleware
res.redirect requires that you pass next
Some members or the Request interface are methods rather than values, such as req.path. req.path is an alias of req.getPath in Restify
I am NOT saying that under-the-hood they are similar, but that the above three things are the main obstacles to porting over Express plugins. Under-the-hood, Restify has many advantages over Express in my experience using it in both large enterprise applications and personal projects.
You need to use redirection status code 302.
res.send(302); or res.send(302, 'your response');
Related
I am overall clueless about how and why you set up a node.js app, and how any of the app.use functions work - the tutorials on it don't explain the why of anything.
Anyway, I have socket.io, res.locals and index.js set up like so in the app.js root file.
const sockets = require('./models/socket')(io)
app.use(function (req, res, next) {
res.locals.user_id = req.session.user_id;
next();
});
const routes = require('./routes/index');
app.use('/', routes);
I'd like to be able to access res.locals in the socket.js model, like I can in index.js found in the routes folder.
I can't guess how to go about doing this. If anybody is able to explain how and why I can or can't that would be a bonus. Thanks!
Welcome to Expressjs, there are a few fundamentals you should probably research before going any further, they'll help solve some of your confusion. I'll give a brief explanation of them but I suggest you do further research. I'll then answer your actual question at the end.
Middleware and app.use
Expressjs is built upon an idea that everything is just "middleware". Middleware is a function which runs as part of a request chain. A request chain is essentially a single client request, which then goes through a chain of a number of middleware functions until it either reaches the end of the chain, exits early by returning a response to the client, or errors.
Express middleware is a function which takes the following three arguments.
req (request) - Representing the request made by a client to your
server.
res (response) - Representing the response you will return to
the client.
next - A way of telling express that your current
middleware function is done, and it should now call the next piece of
middleware. This can either be called "empty" as next(); or with an
error next(new Error());. If it is called empty, it will trigger
the next piece of middleware, if it is called with an error then it
will call the first piece of error middleware. If next is not called at the
end of a piece of middleware, then the request is deemed finished and the
response object is sent to the user.
app.use is a way of setting middleware, this means it will run for every request (unless next() is either not called by the previous piece of middleware for some reason, or it's called with an error). This middleware will run for any HTTP request type (GET, POST, PUT, DELETE, etc).
app.use can take multiple arguments, the important ones for beginners to learn are: app.use(func) and app.use(path, func). The former sets "global" middleware which runs no matter what endpoint (url path) the client requests, the latter (with a specific path) is run only if that specific path is hit. I.e. app.use('/hello', (req, res, next) => { res.send('world'); }); will return "world" when the endpoint "/hello" is hit, but not if the client requests "/hi". Where as app.use((req, res, next) => { res.send('world'); }); would return "world" when you hit any endpoint.
There are more complex things you can do with this, but that's the basics of attaching middleware to your application. The order they are attached to the application, is the order in which they will run.
One more thing, this will blow your mind, an express application made with the standard const app = express() can also be used as middleware. This means you can create several express applications, and then mount them using app.use to a single express application. This is pretty advanced, but does allow you to do some really great things with Express.
Why can you not access res.locals in socket.io? (The real question)
Within your middleware handler, you are setting up a res.locals.use_id property. This only lives with that individual request, you can pass it around as long as the request is alive by passing it into other functions, but outside of that request it doesn't exist. res is literally the response object that tells Express how to respond to the clients request, you can set properties of it during the request but once that HTTP request has ended it's gone.
Socket.io is a way of handling web socket requests, not standard HTTP requests. Thus, in a standard express HTTP request you will not be able to hand off the connection to anything with socket.io, because the connection is a single short lived HTTP request. Likewise, you won't be able to do the same the other way.
If you wish to find the users id in a socket.io request, you'll have to do this within the socket.io request itself.
Right now, you're entering a piece of middleware for an Express.js request, you are then calling next() which runs the next piece of express middleware, at no point does it cross over into Socket.io realms. This is often confused by tutorials because Socket.io can handle requests across the same port as Express is listening on, but the two are not crossed over. So you will need to write separate middleware for both Express.js requests chains, and socket.io request chains. There are ways of writing this code once and then writing an adapter to use it across both platforms, but that's not what you've tried to do here.
I would suggest you look at doing just nodejs and express for a time before taking on socket.io as well, otherwise you're trying to learn a whole heap of technologies all at once is quite a lot to try and take on board all at once.
I want to extend this open topic: Add Routes at Runtime (ExpressJs) which sadly didn't help me enough.
I'm working on an application that allows the creation of different API's that runs on NodeJs. The UI looks like this:
As you can see, this piece of code contains two endpoints (GET, POST) and as soon as I press "Save", it creates a .js file located in a path where the Nodejs application is looking for its endpoints (e.g: myProject\dynamicRoutes\rule_test.js).
The problem that I have is that being that the Nodejs server is running while I'm developing the code, I'm not able to invoke these new endpoints unless I restart the server once again (and ExpressJs detects the file).
Is there a way to register new routes while the
NodeJs (ExpressJs) is running?
I tried to do the following things with no luck:
app.js
This works if the server is restarted. I tried to include this library (express-dynamic-router, but not working at runtime.)
//this is dynamic routing function
function handleDynamicRoutes(req,res,next) {
var path = req.path; //http://localhost:8080/api/rule_test
//LoadModules(path)
var controllerPath = path.replace("/api/", "./dynamicRoutes/");
var dynamicController = require(controllerPath);
dynamicRouter.index(dynamicController[req.method]).register(app);
dynamicController[req.method] = function(req, res) {
//invocation
}
next();
}
app.all('*', handleDynamicRoutes);
Finally, I readed this article (#NodeJS / #ExpressJS: Adding routes dynamically at runtime), but I couldn't figure out how this can help me.
I believe that this could be possible somehow, but I feel a bit lost. Anyone knows how can I achieve this? I'm getting a CANNOT GET error, after each file creation.
Disclaimer: please know that it is considered as bad design in terms of stability and security to allow the user or even administrator to inject executable code via web forms. Treat this thread as academic discussion and don't use this code in production!
Look at this simple example which adds new route in runtime:
app.get('/subpage', (req, res) => res.send('Hello subpage'))
So basically new route is being registered when app.get is called, no need to walk through routes directory.
All you need to do is simply load your newly created module and pass your app to module.exports function to register new routes. I guess this one-liner should work just fine (not tested):
require('path/to/new/module')(app)
Is req.params enough for you?
app.get('/basebath/:path, (req,res) => {
const content = require('content/' + req.params.path);
res.send(content);
});
So the user can enter whatever after /basepath, for example
http://www.mywebsite.com/basepath/bergur
The router would then try to get the file content/bergur.js
and send it's contents.
I need to use an in React Router in order to use Passport.js in my application for OAuthentication. Whenever I create an anchor tag and click it in React it just goes to a blank page in React Router and I don't even get the callback from my Node server on the backend with all the verification from Google/Facebook/Linkedin
What is a useful way to have an href tag in React-Router so that my backend can register it, go through its api flow with the callbacks, and then send it to the right place in React-Router?
The problem is this
The Problem of using axios.get() for OAuthentication with Passport.js
EDIT
In this post they have the same problem that I do and the solution was just a simple href tag, however I have react-router on my application and its possible they did not, also they have no example
Previous post about Authentication with Passport.js with React front
EDIT
I am moving this project from jQuery focused to React, React-Router and Redux so a majority of my server-side Node code didn't need updating but here is ther part of my routes that handles the OAuth with Passport. I just need my front to reach this, let it do its thing and then send back to me
router.get('/linkedin', passport.authenticate('linkedin'),
function(req, res){
console.log('nexted')
}
);
router.get('/linkedin/callback',
passport.authenticate('linkedin', { failureRedirect: '/index' }),
function(req, res) {
console.log('here')
res.redirect('/professionals');
});
I noticed in the comments that you mention having CORS problems, if I'm right I believe you are using the authorization code grant OAuth flow, I had the same issue with GitHub when I had my SPA and my backend in different servers. If this is the case serve the static files of the SPA through the backend server. If you do this you should put the code below as your last route in order for React Router to work. You can find a repo where I did the same here
app.get('*', (req, res) => {
res.sendFile(path.join(__dirname + '/client/index.html'));
});
Note: If you don't want to do this you can use the implicit grant OAuth flow, and make the authentication in the SPA.
My client side code is a single page app (written in knockout.js) with its own routing system so when google crawler bot will try to access links (that have nothing to do with requesting new page from back end BUT just a part of client side routing) it will ask server (node.js + express.js) to serve page (for example 'mywebsite/about') and of course server will return 404 because it unawares of client routing system. Here is my current server code:
router.get('*', function(req, res, next) {
res.sendFile(path.resolve('../dist/index.html'));
});
My idea is to define the same routing structure as in a client and pass routs for client routing system in search parameter:
router.get('/about', function(req, res, next) {
res.sendFile(path.resolve('../dist/index.html?tab=about'));
});
then in client side I can catch it in javascript and pick correct route.
Here off course I have another problem - as I understand google bot doesn't run javascript.. but here I can use prerender.io middleware I guess.
1) Is it a right way to go with single page apps with generated content and SEO?
2) How to pass search parameter from express.js?
If you have query strings that Googlebot can use to recall consistent content then you can indicate this in Webmaster:
https://support.google.com/webmasters/answer/6080548?rd=1
Here's an example set up of mine:
Google wants to only index pages that have consistent content. If content varies for each user - then you want to set a rel="canonical" tag on each page indicating where the 'start' would be for this dynamically generated content.
The idea would be to adapt the Webmaster to your app rather than the other way around. Trying to 'trick' the bot can have dire consequences in SEO because Google does have human checkers that occasionally rate domains. If they find inconsistency between the search indexed URL and what they see in their browser, you'll earn a flag from a lazy operator. Here is the handbook operators follow.
Use prerender.io as first middleware of your pipe:
app.use(require('prerender-node').set('prerenderToken', 'YOUR_TOKEN'));
app.get('*', (req, res) => res.render('index.html'));
First of all, I have read all tutorials on protecting REST API routes with jwt (express-jwt & jsonwebtoken), and it works fine for that purpose.
This works fine:
app.use('/api', postApiRoute);
And this also works, somewhat, I mean.. it does verify the token when I use it to show a webpage with angular http request calls, but when you add expressJwt({secret: secret.secretToken}), you cannot just access localhost:3000/api/post anymore. The expressJwt({secret: secret.secretToken}) is the problem here.
app.use('/api', expressJwt({secret: secret.secretToken}));
app.use('/api', userApiRoute);
What I really need is to protect a non-json but html/text request route with jwt like eg.:
app.get('/admin*', expressJwt({secret: secret.secretToken}), function(req, res){
res.render('index', {
//user: req.session.user, <- not sure how to do the equivalent, to extract the user json-object from the express-jwt token?
js: js.renderTags(),
css: css.renderTags()
});
});
.. without having to make http requests in angular/js, but using express' render function.
I need to do this since my application has 2 primary server routed views, so 1 where admin scripts are loaded from, and 1 where the frontend (theme) assets gets loaded.
I cant however get jwt/tokens to work with server rendered views, only json api requests.
The error i'm getting is: "UnauthorizedError: No Authorization header was found"
Couldn't find any information about (server rendered views protected with jwt, only serverside api requests and client side angular/ajax http requests) this, so I hope my question is clear, and that I do not have to fall back to using sessions again.
Not sure if I understood correctly, but if you are talking about entry html routes (i.e., loaded directly by the browser and not by you angular app), then you simply have no way of instructing the browser as to how to set the authorization header (no without introducing some other redirect based auth flow).