#96 Allow fedoraproject.org TG apps to share FAS cookie
Closed: Fixed None Opened 16 years ago by toshio.

TG apps are using a common session cookie to get connected. Have to set visit.cookie.domain in the tgfas code (python-fedora) to .fedoraproject.org so that we can interchange domains like: bodhi.fedoraproject.org, admin.fedoraproject.org, and mirrormanager.fedoraproject.org

There's a turbogears.config.get(); ideally there's a turbogears.config.set() that can be called when initializing the FAS visit that can do this. That way we don't have to set this within every web application.


I think there's a turbogears.config.update_config() which takes a file, so we can have a separate global configuration file for all of our TG apps. Alternatively, there's a turbogears.config.update, which looks like it takes a dictionary.

https://hosted.fedoraproject.org/projects/bodhi/ticket/88

In this Bodhi ticket, Till raises a question about the security of sending the cookie to more than one web application. While I think the risks there are minimal, the risks associated with sending it to all of .fedoraproject.org seem more pertinent.

Ricky, do you agree with Till's concerns?

Imho it would be better to use a common domain for all applications that use this cookie and are only available via https (no open port 80(tcp)), e.g. .apps.fedoraproject.org or .secure.fedoraproject.org and then move all the applications to this subdomain. You can then savely forward from an http request to the old locations to an https request to the new location without promoting the risk of sending a session cookie unencrypted. Especially when the cookie gives access to a lot more than only one application.

Maybe an alternative would be to use ssl client certificates like koji does and use them instead of cookies, but I do not really know, whether this works.

till: Thanks for reminding us of security concerns with this proposed solution.

Allowing cookies to be sent to .fedoraproject.org is definitely dangerous since it can potentially give pages that we cannot control (http://people.fedoraproject.org/~username/ and possibly the wiki) access to sensitive cookies. The .apps.fedoraproject.org solution should get around this problem, but the SSL cert idea also sounds like a really nice solution as well (with a password-based fallback, if necessary).

Till, does using admin.fedoraproject.org as our server for secure links and setting the cookie to only be transmitted on https connections sound like it will resolve the issues? Or do you think there are still some holes in that scenario?

Ricky set bodhi.fp.o to redirect to https://admin.fp.o/updates today so we're making progress down that path.

Replying to [comment:5 toshio]:

Till, does using admin.fedoraproject.org as our server for secure links and setting the cookie to
only be transmitted on https connections sound like it will resolve the issues? Or do you think
there are still some holes in that scenario?

This solutions sounds good, I do not see any holes there right now.
Somehow related: Can you maybe integrate koji into admin.fp.o, so that ticket:88 will be solved? Koji uses a strange SSL certificate.

With the present redirects, bodhi and packagedb share the fas cookie. mirrormanager doesn't have a mirrormanager.fp.o type domain so it shares the cookie without a redirect.

koji is the odd man out at the moment but we'll work on that in ticket:88.

Login to comment on this ticket.

Metadata