Fix client-initiated ssb-http-auth routes

[staltz]

I'm testing ssb-http-auth between go-ssb-room and manyverse and all the basics are working, but naturally I bumped into a few small issues. Client-initiated auth means that the SSB app generates a URL and the route needs to be exactly /login not /withssb/login, because this specific /login will be the same for all servers that comply with ssb-http-auth-spec (the alternative protocol design is that there would be a muxrpc on the server to ask for its login URL, but this would be one more roundtrip).

I'm thinking that in go-ssb-room, the server could simply detect that if you call /login?cid=${cid}&cc=${cc}, it detects the presence of the cid and cc and redirects you to /withssb/login?cid=${cid}&cc=${cc}, otherwise it does the default behavior of just rendering static HTML to show you the two options (ssb-http-auth or password).

If piggybacking on the presence/absence of cid & cc is ugly, we could introduce a new parameter that makes the intent explicit, e.g. /login?ssbHttpAuth=1&cid=${cid}&cc=${cc}, where 1 works as either "true" or the version of the ssb-http-auth spec. We could update the spec with this ssbHttpAuth=1 param.

[cryptix]

Ah interesting. Yes, agreed. This was mainly why I had the decideMethod() handler on /login. 😃