django-unhosted er en Django app server (lagring) implementering for "stabil" remoteStorage API-versjonen, er angitt her:
http://www.w3.org/community/unhosted/wiki/RemoteStorage-2011.10
Noen deler av det (spesielt webfinger, OAuth2, siden jeg har brukt nyere specs som var tilgjengelige på den tiden) kan være kompatibel med nyere ("eksperimentell") API:
https://www.w3.org/community/rww/wiki/read-write-web-00#simple
http://www.w3.org/community/unhosted/wiki/Pds
Men siden remoteStorage.js 0.7.0 for eksperimentell API er fortsatt under utvikling, har jeg ikke testet om det fungerer med dagens gjennomføring.
remoteStorage
Tanken er at du kan ha lagringskonto (med hva politikk og autentisering) på host1 og noen webapp (si, noen visuell editor, tror MS Word) på vert2.
Til å redigere dokumentet i en webapp, generelt vert2 måtte gjennomføre noen form for brukerregistrering, lagring (som docs.google.com) for redigerte dokumenter etc.
Med remoteStorage, gjør dette lagrings ikke å være på vert2, så du trenger ikke å gjennomføre noen komplekse politikk og godkjent lagring der for å lansere en fullverdig webapp - det kan åpne og lagre dokumenter til enhver ekstern vert som støtter protokollen (som er utgangspunktet GET / PUT fra WebDAV med OAuth2 på toppen).
host1 kan være dine VPS, klient maskin selv (spesielt lett med direkte IPv6, eller IPv4 gitt via noen tjeneste som pagekite), noen pålitelig sky leverandøren eller hva.
For å fullt ut forstå hvordan det hele fungerer, anbefaler jeg å se på OAuth2, WebDAV, kor og webfinger, som er i utgangspunktet alle teknologier som brukes til å implementere protokollen.
Dette django app fullt implementerer web-vendt lagring for host1, komplett med brukerregistreringsskjemaer (valgfritt, brukere kan legges av andre django apps eller via django admin grensesnitt ellers), klienttilgang administrasjonsgrensesnitt og en enkel demo klient.
Sikkerhet
Siden applicaton er et offentlig-internett-vendt grensesnitt til din (muligens viktig) data, og jeg er på ingen måte sikkerhetsekspert eller spesialist, anbefaler jeg å Pentest eller validere koden før lagring eventuelle sensitive data i det.
Tap av data eller korrupsjon er mye lettere å forebygge (og sikkerhetskopier gå en lang vei her, btw) enn utnyttelser av sikkerhetshull, så, igjen, kan du se på koden selv og finne problemer der som jeg har en blind flekk (og ikke minst mangel på ferdigheter) for, og dermed ikke vil være i stand til å finne på min egen.
. Eksempel på åpenbare (til en outsider analyse) sikkerhetshull i et oppbevarings-server gjennomføring kan bli funnet her, lære lession det
Krav :
- Python
- Django
Kommentarer ikke funnet