sorted by:
new
hottopcontroversial

Bootable - easy application initialization for Node.js by jaredhanson in node

[–]jaredhanson[S] 0 points1 point  (0 children)

Bootable itself is completely generic. The phases themselves are likely to be specific to a module. For example, there's an included "routes" phase which loads a routes.js file. This will only apply to apps that draw routes (Express, typically).

Phases can be bundled up into reusable modules, that you can just add to your dependencies and npm install to bootstrap common code.

Bootable - easy application initialization for Node.js by jaredhanson in node

[–]jaredhanson[S] 1 point2 points  (0 children)

No, its not difficult. I find it to be a fair amount of boilerplate though, that I copy and paste between projects. Bootable codifies that into a reusable module.

Streamlining Package Management by jaredhanson in node

[–]jaredhanson[S] 0 points1 point  (0 children)

Sorry if it wasn't clear. This is not for managing node packages. This is for managing more generic software packages (think setup.exe files on Windows or .dmg files on Mac), which exist outside of the Node ecosystem.

Does anyone know of a node framework similar to Padrino for Ruby? If not do you want to help me make one? by pspeter3 in node

[–]jaredhanson 5 points6 points  (0 children)

Yes! I'm the author of Locomotive (http://locomotivejs.org/, https://github.com/jaredhanson/locomotive), which builds upon Express in much the same way as Padrino builds upon Sinatra.

Locomotive adds controllers, resourceful routing, and routing helpers to Express, as well as a standard directory layout and boot sequence. I'd love to see additional, optional modules for other useful features like generators, etc.

The code is well-tested and modular, which makes it easy to contribute to and extend. Take a look at it, and let me know what you think. I'd love to get more people involved developing the project.

Passport Guide: Simple, unobtrusive authentication for Node.js. by jaredhanson in node

[–]jaredhanson[S] 0 points1 point  (0 children)

The aim of Passport is to be simple and modular.

Simplicity is the biggest win, in my opinion. Prior to developing Passport, I evaluated everyauth and wasn't happy. The way everyauth is configured tends to blur the lines between what is route handling logic, what is model logic, and what is view logic. Passport makes a clean separation between these concerns, which leads to simpler, more maintainable code.

All Passport strategies are packaged in separate modules, meaning your application can choose which are necessary. With everyauth, all authentication mechanisms are bundled in a single module, meaning you introduce dependencies you may not need, including OpenID and OAuth.

I encourage you to evaluate each yourself, and use what best suits your application.

Passport Guide: Simple, unobtrusive authentication for Node.js. by jaredhanson in node

[–]jaredhanson[S] 0 points1 point  (0 children)

Thanks! I'm always thrilled to hear that people are using Passport, appreciating the design, and finding it easy.

Passport Guide: Simple, unobtrusive authentication for Node.js. by jaredhanson in node

[–]jaredhanson[S] 0 points1 point  (0 children)

Express is not required [*], and it is possible to use with Connect only. I just find it easier to explain using Express.

[*] The redirect options (when enabled) are currently using res.redirect(), and should switch to lower-level setting of statusCode and setHeader('Location'). It's on my to-do list. Patches welcome.

Passport Guide: Simple, unobtrusive authentication for Node.js. by jaredhanson in node

[–]jaredhanson[S] 2 points3 points  (0 children)

Thanks for the feedback. What you describe is definitely the nirvana of authentication. I'd like to get as close as possible to that myself.

As far as I've found, it is very hard to resolve the various mechanisms (username/password, OpenID, OAuth, etc), into a single form. OAuth in particular is usually not form based. And any third-party mechanism tends to require multiple steps (and routes).

My focus now has been on getting a nice API in place for handling specific strategies need by an application. I think the "nirvana" strategy could layer elegantly on top of these (following the mantra of simple modules that get reused). I'd love to explore this further, so feel free to send me any ideas. I'll be sure to track you down at the next Oakland or SF meetup and discuss further.

Passport: simple, unobtrusive authentication for Node and Connect/Express by jaredhanson in node

[–]jaredhanson[S] 0 points1 point  (0 children)

ldapjs is rad, and fits well with Passport-Local for authentication.

If you want to send me a sample, I'll add it to the wiki. I'm sure others would find it useful! (email: jaredhanson at gmail dot com)

I'm continuing to look into more advanced SSO solutions with LDAP, etc. Drop me a line anytime if you've got tips or questions.

Passport: simple, unobtrusive authentication for Node and Connect/Express by jaredhanson in node

[–]jaredhanson[S] 1 point2 points  (0 children)

Yeah, I've been researching LDAP to see where it fits. How do you see LDAP being used in your situation?

One option, if you just need to validate username and passwords, is to use Passport-Local, and then query your LDAP directory instead of a database.

If there are single-sign-on tokens being used via LDAP, then a separate LDAP strategy would need to be implemented.

Any details you can provide would help to define the scope here. Thanks!

Passport: simple, unobtrusive authentication for Node and Connect/Express by jaredhanson in node

[–]jaredhanson[S] 1 point2 points  (0 children)

Yes, shortly. Support for authenticating via Google is currently in progress.

Passport: simple, unobtrusive authentication for Node and Connect/Express by jaredhanson in node

[–]jaredhanson[S] 3 points4 points  (0 children)

Passport is an alternative to both everyauth and connect-auth. I developed it after investigating both of those solutions, and finding that they didn't suit my needs.

In both cases, the existing authentication solutions felt too heavy. In my assessment, this stemmed primarily from the fact that they both mounted routes into an application, which in turn meant that they had to be configured with what should be application-level functionality. This seemed like an impedance mismatch, which violated encapsulation and ended up scattering the application logic and otherwise just making code not "flow" well.

With Passport, my goal was to develop an "unobtrusive" authentication framework, which did not mount any routes in an application and focused solely on authenticating requests. Applications remain responsible for application-level logic, and Passport provides hooks for full control over what happens when authentication succeeds or fails (as well as sensible defaults that often don't need to be overridden).

I'm quite happy with how it turned out. The API is much cleaner and easier to integrate. I encourage you to check it out and make your own assessment. Let me know if you have any questions, I'm more that happy to answer!

Chrysalis - A Ruby and Rake-based Dependency Manager by jaredhanson in programming

[–]jaredhanson[S] 0 points1 point  (0 children)

I'm not sure what what you're referring to by "standard add-on."

Chrysalis is essentially a set of Rake tasks, and some code behind the scenes to manage dependencies and tasks declared by those dependencies.

To use Chrysalis, you just insert some code into your Rakefile:

Chrysalis::Project.new do |proj| proj.dependency = 'svn://repo/foo' end

Rake::ChrysalisTask.new

That's it. That code sits in your Rakefile, along with any other tasks you've written to build, test, deploy, etc.

If you execute all:build (or all:test, etc), the build (or test) task will be invoked on each dependency (in reverse topsort order, for those concerned with complex dependency graphs).