mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

blog for the day

Browse source
This commit is contained in:
Joey Hess 2013-04-08 17:10:55 -04:00
parent 740ec66dcf
commit 34e162681c
2 changed files with 38 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
doc/design/assistant/blog/day_232__headless_webapp.mdwn Normal file
View file

@ -0,0 +1,22 @@
Developed a way to run the webapp on a remote or headless computer.
The webapp can now be started on a remote or headless computer, just
specify `--listen=address` to make it listen on an address other than
localhost. It'll print out the URL to open to access it.
This doesn't use HTTPS yet, because it'd need to generate a
certificate, and even if it generated a self-signed SSL certificate,
there'd be no easy way for the browser to verify it and avoid a MITM.
So `--listen` is a less secure but easier option; using ssh to forward
the webapp's port to the remote computer is more secure.
(I do have an idea for a way to do this entirely securely, making
the webapp set up the ssh port forwarding, which I have written down
in [[webapp]].. but it would be rather complicated to implement.)
----
Made the webapp rescan for transfers after it's been used to change a
repository's group. Would have been easy, but I had to chase down a
cache invalidation bug.

16
doc/design/assistant/webapp.mdwn
View file

@ -26,6 +26,22 @@ if the transfer display refreshes just as the click is made.)
* allow disabling syncing to here, which should temporarily disable all
local syncing. **done**
## better headless support
`--listen` is insecure, and using HTTPS would still not make it 100% secure
as there would be no way for the browser to verify its certificate.
I do have a better idea, but it'd be hard to implement.
`git annex webapp --remote user@host:dir` could ssh to the remote host,
run the webapp there, listening only on localhost, and then send the
port the webapp chose back over the ssh connection. Then the same
ssh connection could be reused (using ssh connection caching) to set up
port forwarding from a port on the local host to the remote webapp.
This would need to handle the first run case too, which would require
forwarding a second port once the webapp made the repository and
the second webapp started up.
## first start **done**
* make git repo **done**