Changes between Initial Version and Version 1 of Ticket #8486, comment 2
- Timestamp:
- Nov 27, 2015, 4:14:25 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #8486, comment 2
initial v1 2 2 > I'm not sure I understand the use case. Isn't the cookie a randomly-generated identifier that only makes sense in the context of a specific Trac instance? 3 3 4 see http://trac-hacks.org/wiki/SharedCookieAuthPlugin4 see [th:SharedCookieAuthPlugin]. 5 5 6 6 There are two basic cases of interest (probably more, but let's start with two): 7 7 8 8 1. cookies are associated with a single environment; that is, you want different auth for different Trac instances 9 1. cookies are readable across environments on the same server; that is, if you log into trac.example.com/foo you are also logged into trac.example.com/bar (single-sign on) 9 10 10 2. cookies are readable across environments on the same server; that is, if you log into trac.example.com/foo you are also logged into trac.example.com/bar (single-sign on) 11 12 th:SharedCookieAuthPlugin is a very hacky way of doing this. On the other hand, it works, consumes existing code, and should be secure. I welcome better SSO solutions that are easily deployable, pluggable, and exist within the Trac framework and don't rely on other (usually less deployable) software. 11 !SharedCookieAuthPlugin is a very hacky way of doing this. On the other hand, it works, consumes existing code, and should be secure. I welcome better SSO solutions that are easily deployable, pluggable, and exist within the Trac framework and don't rely on other (usually less deployable) software.