Closed opn closed 9 years ago
paul90
commented
9 years ago Running in Farm mode might fix that, as it picks up the site name from the browser request. It might be worth reporting the Raspberry Pi Epiphany browser directly to Mozila, at https://github.com/mozilla/persona
Making security modular is, I think, next on the list. It should then be simple to offer alternative schemes.
But it move the client another step away from the Ruby server, unless we can keep them in step.
WardCunningham
commented
9 years ago I don't think we should worry about the ruby implementation.
Has this issue been addressed?
ozten
commented
9 years ago Essentially it doesn't like any user trying to claim the domain at the ip address of the Raspberry Pi.
Yes, this limitation is by design for Persona, so I wouldn't file a bug over there.
Congrats on getting fedwiki on the Pi 2!
WardCunningham
commented
9 years ago Austin -- Welcome back. We missed you.
I've claimed a site with a numerical address using Persona. This would have been last fall. I just tested and found Persona login still works just fine.
opn
commented
9 years ago Yes farm-mode enables wiki-clients on the LAN to edit without logging in - however the server is not serving separate sites based on the remote IP address - it's serving a single site based on the servers local ip address.
If the server used the remote clients referer (ip) address - then we could have a nice farm-based offline mode for teaching purposes. I have not thought through the security implications of this on a public server though...
paul90
commented
9 years ago however the server is not serving separate sites based on the remote IP address
How would that work? You would never be able to access it. If you want to have a wiki based on the user's IP address they would need to run a server on their own machine. You would also need to ensure that their IP address didn't change.
It really is best not to use IP addresses. Should the IP address change for any reason, some very strange things would happen in the federation. Sites disappearing, and forks pointing to the wrong site, being just two.
WardCunningham
commented
9 years ago A server can be addressed by many names. Our farm mode exploits this flexibility by picking up the name the user uses to address the server and offering content unique to that name.
A server can be addressed from many locations. I think @opn is asking that the server offer unique content to each of these locations. It could do this but it doesn't. If it did do this then I could read and write pages my pages but you would not see them because you would only see and write your pages.
@paul90 explains other limitations here: https://github.com/fedwiki/wiki-node-server/issues/102#issuecomment-125948734
WardCunningham
commented
9 years ago I'm trying to imagine the use case @opn is exploring. I think it works like this:
A small server is set up for the purpose of cooperating on a lan, possibly disconnected from the larger internet. A number of users discover this server by convenient means and begin cooperating using some identity that has been conferred upon them by the network. I think some multi-player games work this way and that "lan parties" were once popular for playing them.
To work in this way wiki would need to distinguish reads/writes to a player's own pages and still allow reads of other players' pages. We do something like this now when a user distinguishes themselves by logging into the origin.
It might be that zeroconf delivers enough identity that players could be known by the names they have given their laptops. As I type this my laptop is known as nr.local and I'm ssh'd into au.local. (I name my laptops after my employers.) I just checked, au.local knows nr.local as 10.0.1.195. It might be able to do better if it tried harder with some sort of zeroconf name server reverse lookup.
In the informal setting of a lan party it might be reasonable to equate individual identity with machine identity. DHCP leases numbers and zeroconf adds to that slightly more persistent names.
I have suggested elsewhere that transient identity be manufactured on first contact and stored in the user's browser as a session cookie. See Zero Steps to Claim. This mechanism has the advantage that an individual's manufactured identity is bound to their laptop login, not just the machine configuration. It has the disadvantage that it relies on wildcard addressing which might not be available within zeroconf. We should check.
I will continue this though in the goals pod as Transient Identity
Today I had some fun getting Fedwiki up and running on Raspberry Pi 2. It runs great. The only issue is the Personal login, when trying to claim the site. Persona complains something along the lines of:
Essentially it doesn't like any user trying to claim the domain at the ip address of the Raspberry Pi. Claiming sites on localhost of the laptops behind the LAN works -so the question is is this an issue with the Pi install or something else?
The other thing that did not quite work is tying to login with the built in Raspberry Pi Epiphany browser - it comes up with a blank login screen in a new window at the url (login.persoan.org/signin) - but then does not offer an email to or any buttons to sign in with - the inside of the frame is blank. That's a pity but not such a big deal - as mainly we want to server a wiki site / farm.
The main issue here is to have the option to remove Mozilla Persona for local hosting. It's not good for a number of reasons - the main one being that one main use-case for local hosting is to be able to serve up sites when there is no internet connection. Mozilla Persona requires a round trip to Mozilla servers at present - this effectively prevents running Fedwiki in a teaching / conference / group situation offline - the only option is to use the browser cache.