[ANN] gorilla/sessions: signed/encrypted cookie sessions and base for custom backends

[Rodrigo Moraes]

Hey all,
I'm happy to announce the preview release of the third member of the
Gorilla family: gorilla/sessions. It provides signed (and optionally
encrypted) cookie sessions and defines a base implementation for
custom session backends. Examples and API docs are here:

http://gorilla-web.appspot.com/pkg/gorilla/sessions/

Key features:

* Dead simple basic API: use it as an easy way to set signed (and
optionally encrypted) cookies.

* Advanced API for custom backends: built-in support for custom
storage systems; session store interface and base implementation;
encoder interface and default implementation with customizable
cryptography methods (thanks to Go interfaces).

* Conveniences: flash messages (session values that last until read);
built-in mechanism to rotate authentication and encryption keys;
multiple sessions per request, even using different backends; easy way
to switch session persistency (aka "remember me") and set other
attributes.

Feedback about the API is welcome. The documentation still misses an
example of custom backend, but I plan to implement one for App Engine
memcache in the next week.

thanks,
-- rodrigo

[Andrew Gerrand]

This is really nice, especially the thorough documentation. Great job!

Andrew

[Mostafa Hajizadeh]

I always knew a web "framework" is not what I need (or even want) for Go, and Gorilla is proving that in the best possible way!

[Rodrigo Moraes]

On Sep 9, 10:33 am, Mostafa Hajizadeh wrote:
> I always knew a web "framework" is not what I need (or even want) for Go,
> and Gorilla is proving that in the best possible way!

Thank you, sir. The http package must be the best framework! :)

-- rodrigo

[Andrew Gerrand]

I'm not sure that we'll ever see a mega framework (like Django) for Go, simply because Go's interfaces make it so easy to build cleanly decoupled components. This is one of Go's major strengths, and Gorilla's design exploits it nicely.

Andrew

[Andrew Chilton]

On 12 September 2011 13:13, d_smi...@rocketmail.com
<d_smi...@rocketmail.com> wrote:
> [snip]
> An advantage of mega frameworks is that hey help guide the development of a
> complete application. A frequent complaint about web development in the
> Clojure ecosystem is that developers have trouble figuring out how to create
> an application from the cleanly decoupled components in the ecosystem. Mega
> frameworks like Django are more specific about what the application
> developer should do.

A disadvantage of mega frameworks is that they are 'mega' and usually
you don't need all the cruft that they offer. And sometimes the stuff
that they do offer isn't even the stuff that you really want. Also, I
don't want any framework to tell me how I should do things, I know my
app better than the mega framework developers.

I'd prefer to pick'n'choose all the bits and pieces that my app
_really_ needs and if someone else's bit of stuff isn't what I want,
I'll go and create a bit for myself and share it back. The way Go and
Gorilla think is how I think - in bits and pieces. :)

Cheers,
Andy

--
Andrew Chilton
e: chi...@appsattic.com
w: http://www.appsattic.com/

[andre....@gmail.com]

About not using all the bells and whistles of a framework, I recall using merb, an alternative to rails. It was written in the same spirit has rails, while being very modular. And you would feel the "security" of using a single framework. Unfortunately, the merb team merged with the rails team to create Rails 3. They were suppose to bring the modularity of merb into rails, but frankly, I don't know to which point they got or if they succeeded, having lost interest in rails a couple years ago.

My point is that a mega framework can add little overhead if well designed and if it adapts to your needs instead of you having to adapt to the framework (well, you have to adapt to it at some point I guess).

If your bits and pieces are built not too "far away" from the language standard library, I guess the result is equivalent to what I'm referring as a well designed framework. Otherwise, it can quickly become a version management nightmare given the fast-evolving nature of the go language and its standard library, and the broad range of features a complex web application requires.

Also, you might end up writing code to hook up bits together, in the end writing some kind of mega framework, depending on many pieces of software. Bless open source for making this a non-issue.

Apologize for the long, poorly written, thinking-aloud nonsense that is this post (I'm not an native english speaker).

[Rodrigo Moraes]

On Sep 11, 10:13 pm, "d_smith...@rocketmail.com"
<d_smith...@rocketmail.com> wrote:
> - The http package does not define a request context and
> how independent components interact and collaborate through that context.
> For example, Gorilla Web includes functions for getting routing variables.
>  If somebody creates yet another mux implementation, they will either need
> to depend on Gorilla Web or define yet another place to get routing
> variables.  The "environment" used in Rack, Ring, WSGI and others is a nice
> solution to this problem.

Brad Fitzpatrick manifested interest in adding a "context" (or
"environment", or... the name doesn't matter) to http:

http://groups.google.com/group/google-appengine-go/browse_thread/thread/a102ad50785c9011

How high this is in his priority list I don't know, but it is high on
mine! :) It is basic infrastructure for components and I hope we'll
see some kind of container for global request variables in Go soon;
that would give packages a uniform way to make some state available.

> An advantage of mega frameworks is that hey help guide the development of a
> complete application. A frequent complaint about web development in the
> Clojure ecosystem is that developers have trouble figuring out how to create
> an application from the cleanly decoupled components in the ecosystem. Mega
> frameworks like Django are more specific about what the application
> developer should do.

I think there'll always be people interested in full stack frameworks;
or solutions packed for more specific purposes. But independent
packages can help with that: a framework developer can pick the ones
that better fit and glue them together in a mega framework, like
Pyramid does... maybe we'll see a Goramyd. ;)

-- rodrigo

Having good, independent packages is a good way to .

[Marc Byrd]

I believe this thread started with something about gorilla?

gorilla has a mux compatible with the built-in http.ServeMux (gorilla's is clearly better).

The argument that the original mux should stay and that gorilla's should not be merged, based on the assertion that go is modular, is not logically consistent.

The choices, given these modularity assertions, are that either the best mux should be merged or no mux should be merged.  The arguments for "why http should be a core package" apply in exactly the same ways to each.  

But once it's decided that it should indeed be core functionality, shouldn't the best possible implementation be used?  If the go community rejects clearly superior contributions on the grounds of spurious modularity arguments, the language will be mediocre.  

A great way to build the language (and its adoption) would be to take advantage of both modularity and convention - the packages included with the core, by default, are ones that are best implementations of the specified interfaces. 

m

[Andrew Gerrand]

On Monday, September 12, 2011 5:33:43 PM UTC+10, Marc wrote:

But once it's decided that it should indeed be core functionality, shouldn't the best possible implementation be used?  If the go community rejects clearly superior contributions on the grounds of spurious modularity arguments, the language will be mediocre.  

I don't see any signs of rejection here. Rodrigo is being praised here for his good work.

The existing http.ServeMux is very simple, and works well in many situations. It's a nice baseline that is easy to maintain, and the interface it's built on (http.Handler) makes it easy to replace.

Gorilla's mux is more convenient for some uses, but it is also a lot more code. That's a maintenance burden, and Rodrigo (the person who cares the most) has full control ownership it.

This is a great situation. Users win (simple baseline available, with the more advanced library easily goinstallable). Rodrigo wins (full control over his library). The Go authors win (less code to maintain).

Go's standard library should not be a place for everything that people find useful. It should provide a solid base on top of which people can build great software.

Andrew

[Rodrigo Moraes]

On Sep 12, 4:33 am, Marc Byrd wrote:
> I believe this thread started with something about gorilla?
>
> gorilla has a mux compatible with the built-in http.ServeMux (gorilla's is
> clearly better).
>
> The argument that the original mux should stay and that gorilla's should not
> be merged, based on the assertion that go is modular, is not logically
> consistent.

While I agree with some of your points, I would not defend the
replacement of the default mux by Gorilla's.

The original mux has a couple of advantages, if you don't mind the
lack of more fine-grained matching options: first, it is the simplest
possible, and this can work well in some situations. But most
important (and a blocker for adopting Gorilla's), it is order-
independent, which guarantees that it will work well with independent
packages registering URLs.

Regex-based routers can't assure full priority ordering. They can
figure out *some* priority (something I avoided; Gorilla's doesn't try
to find the best match based on specificity or other criteria, it just
picks the first that matches), but ordering will inevitably matter in
the end. The price to pay is to take care or centralize URL
registration. This is a drawback that doesn't make it as universal as
the default mux.

There're also multiple ways to do it depending on your needs. A
simpler version supporting variables could leave regular expressions
out. Routing could be more attached to request/response type-guessing
(like in Rails or Spring; I avoided this too). Etc.

But I agree with you that standard packages should be the best
possible, just taking into account some degree of universality.

-- rodrigo