In looking at the Node.js boilerplate app you get with a Bluemix application, there is a package called IBMSecurity. It seems to imply that by merely putting some routes after it, those routes will require a tokenized call from your mobile app.
//uncomment below code to protect endpoints created afterwards by MAS
var mas = require('ibmsecurity')();
app.use(mas);
Is this accurate? If you read the docs here, http://mbaas-gettingstarted.ng.bluemix.net/node#get-started-with-security, it says it locks down everything, not the routes after it. So it appears to be a bit unclear. If support for both is there, it should be mentioned in the docs as it makes the feature more appealing if you can pick and choose which routes are locked down.
#Raymond Camden, if you are asking that the doc section
http://mbaas-gettingstarted.ng.bluemix.net/node#get-started-with-security
describes method to enable application security using authentication, then it is right. I am reading from you question '... says it locks down everything, not the routes after it. So it appears to be a bit unclear. ...'. I do not read anything like that in the doc. Can you please clarify what section/paragraph you are reading that implies it locks down everything?
Related
I suppose this type of topics always exist, but i like to have an specifics opinion for my case.
Since 1/2 month i'm thinking about make a listing web application for my daily life (shopping, due, etc.)
I started out define my object model like this (very simple design model)
Models image
So, i decid to create a NodeJS API for back-end, and Angular 7 for front-end. It's not a technical problem for me to develop the application and the API, but my problem is in the design of this, and particuly to the routes design.
My first suggestion for routes API is :
User :
/users
/users/:id
List :
/lists
/lists/:id
Element :
/elements
/elements/:id
Technicaly it's ok, but i'm not sure it's the good practices.
As User contains List and List contains Element, Wouldn't it be better to have routes like this :
/users/:id
/users/:id/list
/users/:id/list/:id
/users/:id/list/:id/element
/users/:id/list/:id/element/:id
Thanks for your answers, or suggestions !
PS : If you have any web sites / video / topics ... to suggests, do not hesitate.
I'd say you got it OK in the first place, the second approach is messy as you can get huge routes, and you're sending a lot unnecesary data. Why do you need the user id to get an element? An element is an entity by itself, and it will probably grow, you may need to get related elements, filter them... its better to just have /elements
What you can do is find simple relations, like:
/users/:id/lists
/lists/:id/elements
I'd recommend reading building apis you won't hate :)
Firstly you are in absolute correct path of defining Routes in angular, at the same time you have to use Lazy loading concept of Routing.
I would recommend you to, go for plural sight course , by Deborah Kurata. I'm not trying to promote or advertise anything but for your current situation that course would be the right guidance. It would provide you all the necessary things that you need to build enterprise ready apps.
Alternatively Core UI Angular provides some best designs which are already implemented with Angular Route and things. Lazy loading and other Angular routing are implemented, all you need to do is understand it.
Hope this helps.,
Principle
as short as possible
easy to read
user-friendly input when the user enters the URL
Examples
User list
/users
User detail
/user/:id
Add user
/user/new
User's functional page
/user/:id/tel
I'm looking into node.js which really seem like a pretty nice environment. I've worked with a lot of different Technologies and for server, mainly php and Java (jsp), but dabbled in som RoR and Python.
I find node.js really easy to get up and running and it feels quite natural to work with, and I found some good entry level tutorials.
I just am missing some more intermediate resources. For example when creating bigger frameworks or api's how would you structure or architect it. I set up some smaller api's to try it out where it would go something like this:
I've made use of the Express framework to create a http server, listen to a port, set up an express object and bound some requests.
However these have been quite small, and the purpose has been learning, if I think about scaling up the size of the API for production, perhaps wanting to do other stuff like serve web-pages as well. I find it hard to see how the architecture would look.
It's vague as I am still new to node.js but I'm mainly thinking about things like if you typically keep all api in one file or if there are good ways to split it up into modules? And if anyone know any resource talking a bit more about how to design the architecture when working in node.js
Sorry for the vague question and thanks for reading.
In my opinion, Express is the good way to go if you want to build complex or big APIs.
It is among others easily testable (for instance with Mocha or Jasmine) and customizable, especially thanks to its middlewares.
For the directory structure, what I usually use is (at least) the following:
app.js : the main entrypoint. Will create the express application, indicate which controller to use for every route prefix, and assign the middlewares. Example from a previous project
controllers : will contain the controllers, the functions which will handle the requests, in the same style as in standard MVC frameworks (e.g. UserController, ...). Each controller would create an express Router object and export it. Inside the controllers, individual handlers are in charge of individual API requests, such as /api/users/list. It would use some library to access your data (e.g. Mongoose for MongoDB), and would then send the response to the client. Example (UserController.js)
models : will contain the models with all their attributes and methods. In my case, it would be the Mongoose models. Example (Song.js)
middlewares : will contain the various middlewares of the project. A practical example would be a middleware checking for an access token in the incoming request, and returning a 403 HTTP error if not. Example (AuthMiddleware.js)
helpers : various helpers
tests : unit tests of you API
This could be the minimal directory organization. On top of that, you may want to use a templating engine such as EJS to serve webpage. Take a look at « Use EJS to template your node application ».
This is only to give you an overview of what an express directory structure could look like, but there are of course plenty (better?) other possibilities. Hope that gives you a quick and useful insight :)
I am using Express to expose a REST API in my Node.js application. When a REST request comes in, I extract the user information from the HTTP headers. I would like this information to be available throughout the life of this request, no matter what function I am in. An obvious but kludgy way is to pass around the user information as parameters to all function calls. Is there a better way? So far I have found the following solutions, but I am not sure if they are ready for prime time:
StrongLoop Zone Library: Docs say "The zone library and documentation are still under development: there are bugs, missing features, and limited documentation."
Continuation-Local Storage: Not sure if this is slated to be part of Node.js. This issue at the end recommends looking at StrongLoop zone.
Node.js Domains: Does not look like this actually took off.
I'm not sure if you're still looking, but a while back I built express-http-context for this very purpose. It's an express middleware that sits on top of cls-hooks (formerly continuation-local-storage).
Full disclosure: this is an npm package that I built and maintain.
I'm trying to figure out how best to architect my app. But for starters trying to understand typical practices with respect to where to put things, and how the app should wire up to things like server.js, how server.js should work, and how you keep a persistent connection open for the website, and any backend services or modules.
This is a general question but let me try to be more specific, as specific as I can since I am new to Node.. and for a basis to start on with this question.
Lets say I plan on designing a simple Express App.
I've got this kind of structure for example so far:
Right now in server.js, I am just playing around with trying to connect to a mySQL database. So I've got a connection pool I'm creating, one call to the store to retrieve data, requires at the time for the node-mysql middleware I'm using, etc.
app.js just has very simple code, it's not modular yet, or even production ready but that's just me playing with the code, spiking things out. So in it I have you're typical stuff like setting the view, var app = express();, importing an express route definition from another module in my routes\index.js, stuff like that.
if I'm going to keep a database connection open, or other things open, how is that best organized/done by convention?
If you look at this example code, he's moving the var app = express() definition into service.js: https://github.com/madhums/node-express-mongoose-demo/blob/master/server.js. He keeps an open connection running and started from there, which makes sense, hence "server".
so should app.js do much? what is best practice or scope of what this should be doing. Once I start modularizing things out into their own .js files and node modules, how does the app.js morph through all those refactorings, meaning in the end what's its role and is it very thin in the end where it's just used to wire stuff up?
Then what should www.js which is now required by express 4 have and it's role?
It's kinda hard for me to start with just one aspect so I'm kinda going all over the place here in the above. I just want to know common conventions for putting stuff in app.js vs. server.js and then best way to keep and managed open connections to things...both in the backend and front-end such as http requests coming in, what should be the central point? routes of course but then so is app.js responsible for referencing routes?
I have found a few resources such as this but looking for more so if you know any or have any input, please reply. I'm more interested in the talk around app.js, server.js, connections, www.js, and where things should wire up to each other with these particular specific parts. I realize the rest is up to you on how you wanna name folders, etc.
There is no right way and (arguably) no wrong way. There are which are better than others, but then someone might say that they don't like this way and you should do it the other way and so on, until your project is over the deadline.
I often refer to this blog post about best practices when developing an express app.
You could also try one of yeoman generators. Choose one that suits most/all of your needs.
Bottom line, there is sadly still no answer to best structure of an app, I would recommend you to pick something that works best for you (and your team) and stick with it. Consistency is the most important thing to keep in mind while developing and JavaScript community it clearly lacking it.
I've been using ember, node, express since 2 months ago.
I've developed an small app, now it's time to add user auth to it but I can't figure out how to do this.
There are a few questions I have:
1.- In SPA apps, where there's only index.html, I include all .js ember files. So, the user could be able to see all the app logic without auth?. How can I add the libs only when the user has been auth?
2.- What's the right way to auth in ember? I haven't seen a solution in official documentation.
3.- How the frontend communicates with the backend, what's the logic here? It's in every route?
Also I'm looking for an example or tutorial.
Thanks you!
I believe these videos target exactly your question
http://www.embercasts.com/episodes/client-side-authentication-part-1
http://www.embercasts.com/episodes/client-side-authentication-part-2
just to mention a great resource for ember tutorials http://emberwatch.com/ - it contains screencasts, books, talks.. articles - all you need to get started.
There is nothing bad about "seeing logic", you are protecting data, not code. Still, if you really want to protect your code, you can create a separate login page and require authentication for every other resource (app html, styles, scripts, etc.). But protecting EVERY resource of your app means that you can't delegate handling static files to nginx or cdn or whatnot. So, think carefully.
There are to approaches: embedded authentication and separate login page. For the first one you can use https://github.com/Vestorly/torii or https://github.com/simplabs/ember-simple-auth. If you decide to go with the second, you can just use authentication provided by your backend (passport.js, etc) and redirect to login page on failures.
Nothing special, you just write your model methods and handle possible authorisation errors. You might also want to have a user object around to use in your template and route logic.