SASL Support #15

ericallam opened this Issue Oct 26, 2011 · 17 comments


None yet
8 participants

Just wondering if there were any plans on supporting SASL authentication. The use case for this is heroku's memcache deployment requires SASL to work. Thanks for your time.


3rd-Eden commented Oct 26, 2011


SASL auth isn't on my todo list. Because I don't use it. But I'll be more than happy to accept a pull requests for it ;)

calaniz commented Mar 24, 2012

+1 for this. Alot of the cloud memcache providers require authorization via SASL. This would be a great to have.


3rd-Eden commented Mar 26, 2012

Adding SASL might a nice feature, but I have no experience with SASL authentication so it's going to be huge task for me to implement it

On Saturday, March 24, 2012 at 11:22 PM, Cesar Alaniz wrote:

+1 for this. Alot of the cloud memcache providers require authorization via SASL. This would be a great to have.

Reply to this email directly or view it on GitHub:
3rd-Eden#15 (comment)


3rd-Eden commented Sep 14, 2012

Decided not to add SASL support as this requires me to support 2 different parsers a ASCII parser and a BINARY parser as SASL support can only be done if you communicate on a binary level with memcached.

The reason I want to keep the ascii support is that there are a lot more databases/message queues that are adding support for the ascii memcached protocol so going full binary is not an option here and supporting 2 parsers is a bit overkill.

@3rd-Eden 3rd-Eden closed this Sep 14, 2012

potomak commented Mar 8, 2013

This is the reason I'm working on (

I'm working on a project using @addisonj, it relies on your library to use memcached but I'd like to deploy the app on Heroku using the MemCachier addon.

How much money will you need to implement this feature?

/cc @alevy @alexlod @dterei


3rd-Eden commented Mar 8, 2013

One hundred billion dollars

But in all seriousness, I honestly don't know how much time it will cost to implement an extra parser in to the source. But I do know that it's impossible to do in the current version as the parser is completely is implemented throughout the module. Having that said, It might be do-able for the 1.0 release that I have been slowly working on. It features a new ASCII streaming parser that resolves tons of edge cases and has a huge performance increase. So I can see I can create an API that is compatible with the

potomak commented Mar 8, 2013

Shut up and take my money

Thanks anyway. I'm trying


ronkorving commented Mar 8, 2013

Can I just +1 this for entertainment value? Thanks guys :)


3rd-Eden commented Mar 8, 2013

@potomak I'm just gonna re-open this and put in under the 1.0 milestone.

@3rd-Eden 3rd-Eden reopened this Mar 8, 2013

potomak commented Mar 8, 2013

Thanks @3rd-Eden

dterei commented Mar 8, 2013

Ha, this was awesome! Yes, for now (with MemCachier on Heroku) due to lack of SASL and binary protocol in node-memcached we recommend using our own homegrown memcache client for node ( @3rd-Eden Let us know though when you feel the code base for node-memcached is in a state that is suitable for adding the binary protocol and SASL, it's something we could probably help out with.

alevy commented Mar 9, 2013

@3rd-Eden @dterei if it makes sense to combine efforts as well, we can see about merging memjs into node-memcached. Maybe it doesn't, and it's better to have separate libraries for ascii and binary, but I'm definitely happy to try and join forces.


3rd-Eden commented Mar 16, 2013

@alevy First of all apologies for the late response, It's been a really busy week and this issue has totally slipped my attention.

There are 2 ways we could collaborate:

  1. On memcached client level, where we unify merge our projects in to one single project which would probably result in the best memcached client for Node.js. This would probably only be an option if we share the same goals for the project. I have taken a look a your memjs project and it looks like a really solid implementation of the binary protocol and want to support a couple of thing that I have already build in to this project. My main goal of the driver was to build the highest performing memcached driver that supports multiple server through consistent hashing with a decent fail over solution for broken servers.
  2. If we differ in visions we might be able to collaborate on a parser level. As I have recently started extracting and rebuilding my ASCII parser in to a new project (memcached-stream) which is a streaming response parser. It might be worth integrating a binary protocol in to that project which both of our projects use and maintain.

Anyways, love to hear your thoughts on this.

alevy commented Mar 20, 2013

@3rd-Eden, it sounds like it makes sense to try and merge. I'll take a look at this library as well as memcached-stream and see which would be the easiest starting point.


ronkorving commented Mar 21, 2013

Just a friendly word of caution. The binary API and ascii API are not the same. The binary one is much richer in its abilities, and it would be a real shame if some of that would be lost for the sake of unification.

Dids commented May 3, 2017

I'm assuming there are no plans to implement this?


3rd-Eden commented May 3, 2017

@Dids Personally, no, because I wouldn't use it but if you want to contribute support for it we're open for PR's.

@balor balor referenced this issue in balor/connect-memcached May 4, 2017


No authentication? #31

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment