Positives --------------- >> 1. simple for users and remember >> 2. not overlapping with any of the older apps or existing urls >> 3. futureproofing for new apps or different interfaces >> 4. expanding the number of apps we have w/o having them grouped under a >> single project (like community was). Negatives ------------- >> - no interest in pinning anything/everything behind admin.fp.o Why can we not forward everything through a filter? For instance: www.fedoraproject.org/render?project=FOO 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). 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? :-) _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
