Permalink
Browse files

Reworking of code structure and web.py starts

Mostly a complete revamp of how the layout should be for holding the code.
The idea is that the user can download a tarball, untar it to the web root
directory, make the necessary web server changes, and launch the site.
Also, this marks the beginning of developing against the web.py framework.
None of the code is working at the moment. Just a skeleton to get going.
  • Loading branch information...
1 parent 6eb503c commit e44cfa5354cfc25489fb6e04892a6965d949b487 @xmission xmission committed Jul 26, 2012
View
@@ -50,3 +50,102 @@ Ideas
* Image generation to create copy/pastes.
* If copied, set JavaScript timer to clear clipboard in 1 minute.
* Randomize clipboard to discourange key logging.
+
+Python Documentation
+====================
+
+URL Generation
+--------------
+
+URLs for self destructing notes should not be predictable in any manner.
+Thus, a 22-character base64-encoded string is generated for each
+submission. This will give us enough random URLs to avoid a collision with
+1 in 2^122. The code should be self-documenting, however, this might
+explain things a bit more clearly.
+
+Each URI starts with using data found in /dev/urandom by using the uuid
+module with `u=uuid.uuid4()`. This gives the source of the URI 122-bits of
+entropy, by using the randomness found in the UUID v4 RFC, which should be
+sufficient for generating URLs.
+
+We then encode the string using `base64.urlsafe_b64encode(u.bytes)[:22]`
+from the base64 module. This gives us 22 characters for our URL. The valid
+characters for our URLs are thus:
+
+ ABCDEFGHIJKLMNOPQRSTUPVXYZabcdefghijklmnopqrstupvxyz0123456789-_
+
+So, a valid URL for your self destructing notes could be:
+
+ https://exmaple.com/cWQI4m3fRcW8zM_Mdeg3uQ
+
+There are some notes to consider with this URL scheme:
+
+* UUID v4 has the format XXXXXXXX-XXXX-4XXX-MXXX-XXXXXXXXXXXX, where '4' is
+statically defined, and 'M' can be 8 9 a or b.
+* With the raw bytes converted to base64, some characters are predictable.
+Its format is XXXXXXXXMXNXXXXXXXXXXXO, where 'M' is either QRST,
+'N' is either -26aCeGiKmOqSuWy and 'O' is either AgQw.
+
+Regardless, the server would need to be processing 1 billion URLs every
+second for 100 years before we reached the probability of 1/2 for
+generating a duplicate URL.
+
+d-note does not keep track of which URLs have been generated. Thus, it is
+possible, although highly improbable, that the same URL could be generated
+for two different form submissions. Of course, the application will check
+against any valid notes that have not yet self destructed, but will not
+check for ones that have.
+
+Thus, it is possible that a URL that has already self destructed could be
+regenerated at a different time, which has not self destructed. If the
+first URL is publicly accessible, that means that the second URL could be
+opened by the wrong recipient accidentally. As such, these URLs should be
+kept as private as possible to prevent this from happening.
+
+JavaScript Documentation
+========================
+
+Hashcash
+--------
+
+The point of a Hashcash implementation is to prevent form spam. I'm not
+sure what the benefit of spammers would be to use self-destructing notes,
+but nonetheless, I'm not really interested in entertaining it.
+Implementaning Hashcash as a proof-of-work system is simple enough to
+deter most spammers. The breakdown is as follows:
+
+* Server gets client IP address.
+* Server generates nonce.
+* IP address and nonce become the resource string.
+* The resource string is embedded invisibly into the form.
+* Client then mints a Hashcash token based on the resource string found.
+* The client submits the form with the minted token.
+* Server verifies if the token is valid.
+ * If valid, the form submits.
+ * If not valid, the user is notified submission failed.
+
+A resource string with IP address "65.100.223.163", and nonce "VILymxxv"
+generated by the server could look like this:
+
+ 65100223163VILymxxv
+
+A minted Hashcash token generated by the client would then need to look
+something like this:
+
+ 1:20:120715:65100223163vilymxxv::lVb6gfTxYb1Ir5SW:COBt
+
+This is valid, because the SHA1 hash of the above token is:
+
+ 00000bed07757ed13f1f2cebc67b616c75812b41
+
+which starts with 20-bits of leading zeros. The work is forced on the
+client, which inserts the token into the form. Even on modern hardware,
+this should be a strenuous task on the client CPU, and could take up to a
+second or two to create a valid token string. However, the server can
+verify the token quickly (in nanoseconds).
+
+The minting of the token should be done in the background while the user is
+typing the note in the form. Thus, when the submit button is pressed, no
+additional waiting is needed.
+
+More info can be found at http://hashcash.org.
View
@@ -0,0 +1 @@
+SHARED_SECRET = 'm8sQai6lbg?C)PI%Bkd|@1VSR,mikqy)' # CHANGE ME!
View
No changes.
View
No changes.
View
@@ -1,13 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html>
- <head>
- <script type="text/javascript" src="../javascript/hashcash.js"/></script>
- <script type="text/javascript" src="../javascript/sha1.js"/></script>
- </head>
- <body>
- <form id="submit">
- <input type="hidden" id="hashcash" value="19816211AbCdEfGh"/>
- <button type="button" onclick="validate_token()">Submit</button>
- </body>
-</html>
View
No changes.
View
@@ -0,0 +1,27 @@
+import web
+import view
+import config
+from view import render
+
+urls = ('/', 'index')
+render = web.template.render('templates')
+
+class index:
+ def GET(self, url):
+ if url == "":
+ page_file = 'index'
+ page_file = 'notes/%s' %(url)
+
+ try:
+ f = open(page_file, 'r')
+ except IOError:
+ return web.notfound()
+
+ content = f.read()
+ return render.page(content)
+
+if __name__ == '__main__':
+ app = web.application(urls, globals())
+ app.run()
+ app.internalerror = web.debugerror
+
View
@@ -1,47 +0,0 @@
-JavaScript Documentation
-========================
-
-Hashcash
---------
-
-The point of a Hashcash implementation is to prevent form spam. I'm not
-sure what the benefit of spammers would be to use self-destructing notes,
-but nonetheless, I'm not really interested in entertaining it.
-Implementaning Hashcash as a proof-of-work system is simple enough to
-deter most spammers. The breakdown is as follows:
-
-* Server gets client IP address.
-* Server generates nonce.
-* IP address and nonce become the resource string.
-* The resource string is embedded invisibly into the form.
-* Client then mints a Hashcash token based on the resource string found.
-* The client submits the form with the minted token.
-* Server verifies if the token is valid.
- * If valid, the form submits.
- * If not valid, the user is notified submission failed.
-
-A resource string with IP address "65.100.223.163", and nonce "VILymxxv"
-generated by the server could look like this:
-
- 65100223163VILymxxv
-
-A minted Hashcash token generated by the client would then need to look
-something like this:
-
- 1:20:120715:65100223163vilymxxv::lVb6gfTxYb1Ir5SW:COBt
-
-This is valid, because the SHA1 hash of the above token is:
-
- 00000bed07757ed13f1f2cebc67b616c75812b41
-
-which starts with 20-bits of leading zeros. The work is forced on the
-client, which inserts the token into the form. Even on modern hardware,
-this should be a strenuous task on the client CPU, and could take up to a
-second or two to create a valid token string. However, the server can
-verify the token quickly (in nanoseconds).
-
-The minting of the token should be done in the background while the user is
-typing the note in the form. Thus, when the submit button is pressed, no
-additional waiting is needed.
-
-More info can be found at http://hashcash.org.
File renamed without changes.
File renamed without changes.
View
@@ -1,37 +0,0 @@
-Python Documentation
-====================
-
-URL Generation
---------------
-
-URLs for self destructing notes should not be predictable in any manner.
-Thus, an eight-character base64-encoded string is generated for each
-submission. This will give us enough random URLs to avoid a collision with
-1 in 281,474,976,710,656. The code should be self-documenting, however,
-this might explain things a bit more clearly.
-
-Each URI starts with using data found in /dev/urandom by using
-`s=os.urandom(72)`. This gives the source of the URI 72-bits of entropy,
-which should be sufficient for generating URLs.
-
-We then encode the string using `base64.urlsafe_b64encode(s)[:8]`. This
-gives us 8 characters for our URL. The valid characters for our URLs are
-thus:
-
- ABCDEFGHIJKLMNOPQRSTUPVXYZabcdefghijklmnopqrstupvxyz0123456789-_
-
-So, a valid URL for your self destructing notes could be:
-
- https://exmaple.com/i55GWOnH
-
-d-note does not keep track of which URLs have been generated. Thus, it is
-possible, although highly improbable, that the same URL could be generated
-for two different form submissions. Of course, the application will check
-against any valid notes that have not yet self destructed, but will not
-check for ones that have.
-
-Thus, it is possible that a URL that has already self destructed could be
-regenerated at a different time, which has not self destructed. If the
-first URL is publicly accessible, that means that the second URL could be
-opened by the wrong recipient accidentally. As such, these URLs should be
-kept as private as possible to prevent this from happening.
View
@@ -0,0 +1,10 @@
+$def with (content)
+<!doctype html>
+<html>
+ <head>
+ <title>Testing</title>
+ </head>
+ <body>
+ $:content
+ </body>
+</html>

0 comments on commit e44cfa5

Please sign in to comment.