Connection issue with redis_session

[Brian Looker]

Hi all,

I'm relatively new to Pyramid, coming from Flask. It's exciting working with a framework that doesn't do everything for me, but also intimidating in terms of the number of options it enables me to use.

I'm looking at using redis_session for sessioning following the advice on the Pyramid site that use of the built-in session library is less secure. If I'm misunderstanding that, I welcome correction, because I really do not need to add any persistence to this web application aside from storing current user session info.

I'm receiving the following error:
ConnectionError: Error 111 connecting to localhost:6379. Connection refused.

I have followed the instructions for installation and configuration. However, I have done no additional installation of Redis on my computer. Is the fix as simple as sudo apt-get redis-server, or should redis already be available given my following of the instructions?

[Jonathan Vanasco]

pyramid_redis_session requires storing sessions on a redis server... so you need to install redis on your machine AND create a database/password on redis.  

redis is a GREAT solution for managing server-side session data.  if you don't need to store data server side though (because it is very small, or does not need to be shielded from the public), pyramid supports client-side session data in the form of signed cookies (i think there are encrypted cookies in the base too).

[Brian Looker]

My web app grabs data via API routes, populates a form with it from which users select options, and upon submission of the form sends off some emails. I don't need to store data anywhere as the API routes give me access to the most up-to-date information, so it sounds like client-side storage would work best. The most essential piece I can see for storing any session data at all is to confirm the user's credentials for passing requests to the API routes.

Is the signed cookie session factory okay for production use if implemented with encryption?

[Jonathan Vanasco]

Sorry a bit confused about the types/locations of data you're talking about.

Also I checked and pyramid does not have encrypted cookies.  Sorry. I thought I read that someone had released a package; maybe it was a 3rd party plugin.

Anyways...

If your session has some sort of abstract 'account identifier' in it, and that matches up with some sort of database or hardcoded user info, you should be fine with a signed cookie.
If your session has some sort of 'credentials' in it that the API needs to work (like a login/password), I would encrypt that payload.  I would also prefer to route it through https if the encryption is not very strong.

[Tom Lazar]

FWIW we've been using 'regular' cookies with content encrypted by http://pythonhosted.org/itsdangerous/ for many projects now. Works like a charm. 

Sent from a phone, please excuse the brevity.

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[Laurence Rowe]

From a quick read through, itsdangerous is a signed cookie implementation, equivalent to the builtin pyramid.session.SignedCookieSessionFactory.

Signed cookies are usually just fine, you only need encryption if you want to prevent the user from inspecting the content stored in their cookies.

[Jonathan Vanasco]

On Saturday, May 16, 2015 at 5:12:08 PM UTC-4, Laurence Rowe wrote:

Signed cookies are usually just fine, you only need encryption if you want to prevent the user from inspecting the content stored in their cookies.

Encryption is also needed if you want to prevent others on the network from inspecting cookie content.  I've seen a few apps where the developers stored 3rd party auth information in a cookie; while it's fine for users to access that info and for to merely be signed as "proof" it was already registered with the application, unless that content is locked to HTTPS it can be visible in network traffic.

 

[Brian Looker]

Thank you for the insight. Looking over the SignedCookieSessionFactory, I have two questions. How do I ensure that HTTPS is used? What is the "secure flag" of the session cookie?

Jonathan, you mentioned my description of types/locations of data being confusing. To clarify, I'm creating a web app on my server that grabs data from third-party software on a remote server using API routes the third-party has provided. This other party handles all of the authentication--my web app sends users to the third party's login page to login, and then they are redirected back to my app. That redirection includes authorization tokens which my app uses to build a user context. This user context is included in API requests to the third-party's system in order to authorize the calls. If this context were visible, it would not be difficult to take the user context tokens from the request. These tokens could be used to make other calls to the third party's system, so it's important that they are kept secret.

--

[Jonathan Vanasco]

Cookies (in general) have a few flags:

* httponly - tells the browser to only send to severs; not allow JS access 

* secure - tells the browser to only send to secure servers (https, i think there are other secure methods too)

Pyramid (and many other python packages) usually abstract them into boolean arguments, which is what you see in the cookie/session api.

You definitely want to use encryption in your scenario.  Most third-party login APIs will require you to have the endpoint under HTTPS (facebook and twitter, for example), so I would personally just run all of this under HTTPS with signed cookies from Pyramid's default factory that are httponly and secure. That would be reasonably secure enough – it will protect the data as network traffic, and compromising the security would entail compromising HTTP or one of the machines involved.    To tell what type of connection you have, `request.scheme` will tell you if a request is 'http' or 'https' .  It's a `webob.Request` property; it may be influenced by frontline / proxy servers that fail to convey the right headers to wsgi so you should have some deployment tests that ensure the correct setup.

If you have to run on HTTP, then you'll need to encrypt/decrypt the payload of your cookies.

[Brian Looker]

Thank you very much for the help. I've fleshed out the program a bit more, running a localhost on my machine, and setting the secure flag to True is raising a couple of issues. First, I run into a KeyError while pulling data from the session, which does not happen while secure is set to false. Also, I've been printing request.scheme to the console to see if "https" has been used, but it is printing "http."

I'm looking through the documentation, but would be grateful for any insight into this.

Peace,
Brian

[Jonathan Vanasco]

What I'd imagine happening is this:

1. You're connecting on http, not https so...

2. The key isn't in the session, which will (correctly) raise an issue.

If you're doing https, I think you need to put Pyramid behind something (i'm not sure if pserve can handle https or not).

I run nginx on my macbook and proxypass back to pserve

so it looks like this:

    pyramid serves my project on port 5000

    nginx proxypass localhost http traffic (port 80) to port 5000

    nginx proxypass localhost https traffic (port 443) to port 5000

i believe the default nginx settings will convey the https status of the connection to wsgi (waitress/pserve)