new web app urls discussion

[Kevin Fenzi]

On Mon, 23 Jan 2012 09:59:08 -0500
"Adam M. Dutko" <dutko.adam at gmail.com> wrote:

> 
> Why can we not forward everything through a filter? For instance:
> 
> www.fedoraproject.org/render?project=FOO

well, thats hard for people to remember and tell to others. ;) 

> where render is a rewrite to a method that determines which host a
> particular project resides on. This approach would scale and seems to
> fit the requirements. In terms of making it "easy for users" we would
> still have to come to a consensus on whether to use
> FOO.fedoraproject.org or www.fedoraproject.org/FOO. Either way these
> could then be mapped "internally" through our proxy/webserver of
> choice to the proper rendering method + option(s).

Well, we already do this with our proxy setup, but we want to usually
keep the url constant so it doesn't confuse people. Also, we need to be
carefull with the csrf stuff, and the domains for sharing cookies. 

> I imagine this solution might cause a problem with SSO and cookies so
> it might be a non-starter unless we are able to migrate to more of a
> unified RBAC model where someone authenticates to our "root" domain
> but then access to other applications is granted per site. Such an
> approach might also help cleanup the authentication, authorization and
> accounting (AAA) issues new applications sometimes experience by
> enabling us to write a "clean authentication module" developers can
> import to make their application "Fedora Project AAA Compliant." A big
> task indeed but it might help with NIHS for new applications.
> 
> Maybe I didn't think this through? thoughts, suggestions,
> explicatives? :-)

Yeah, I don't know that I like this for the cookie and readability
reasons, but thanks for the ideas. ;) 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20120123/213d4d5f/attachment.sig>