DRH wrote: > Here again, we need to be mindful of security. Miscreants can easily forge > an x-forwarded-for: line in an HTTP request and in the default > configuration > Fossil allows requests requests from 127.0.0.1 to bypass the login > mechanism. (That login bypass for 127.0.0.1 makes the "fossil ui" command > much more convenient.) So at the very least, we would want to check the > value supplied by x-forwarded-for and make sure it is not 127.0.0.1. In > addition, we might want to disregard x-forwarded-for completely unless the > real REMOTE_ADDR is 127.0.0.1, or perhaps some other well-known address > specified on the "fossil server" or "fossil http" command-line. In other > words, disregard x-forwarded-for unless the request is coming from a known > trusted host.
I accept your points on security. When used on a company network (in a larger company), the "fossil scgi" command needs to be limited to trusted clients as well. I think it is worth thinking about the commands, so that they remain understandable and intuitive also for new or casual users. Currently I'm thinking along the lines of three forms of the server command. Now we have "fossil server" and "fossil ui", which should stay as is. Perhaps it needs a third form along the lines of: fossil backend http|scgi [-P port|pipe] [-F front-server-ip] [-R repository] Not sure yet, I'll think about it a bit more. All input welcome. Paul _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
