| Age | Commit message (Collapse) | Author |
|---|
|
the code was so secure to injections, that even the form fields were not
allowed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The application is now expected to only receive authenticated
request; the user_id is available in the X-Remote-User header.
The @login_required decorator creates the session cookie from
this header.
|
|
On veut être sur qu'il n'y a pas d'injection sql possible à travers
le nom des colonnes, donc on utilise une whitelist.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- also turn on foreign keys support in sqlite3
|
|
|
|
|
|
|
|
|
|
|
|
This is handled in javascript. When clicking the edit link:
1. a form is shown to edit the RST source of the comment.
2. on submit, an AJAX POST request is sent to the new "comment" endpoint in the
flask app.
3. the endpoint compiles the RST source, update the comment in the database and
sends back formatted content to the client.
4. the client then updates the comment content and hides the form.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
before it was reloaded every time due to the @app.before_request
now it's loaded on demand.
|
|
|
|
|
|
not that well tested, so might kill your kitties.
|
|
Ca a l'air de marcher, mais pose la question suivante:
Pourquoi pas se débarasser du champ timezone dans la base de donnée
et faire la conversion directement au niveau du javascript?
L'avantage étant que l'utilisateur n'a aucun réglage à faire car
le navigateur a accès à la timezone du système qui est sans la doute
la première chose que l'utilisateur change.
|
|
|
|
|
|
|
|
|
|
|
|
I can't make the user edit template work
The dropdown doesn't default to the current timezone.
|
|
|
|
|
|
* Make flask db connnection also use date converters to avoid crashing
when displaying dates
* Update the import script to import dates from the old databse as timestamps
By the way, I strongly disagree with this choice of using timestamps, for the
following reasons:
* why would timestamps be a better representation of times than ISO 8601? they
cannot represent times before the epoch, they are more easily subject to "year
2000"-like bugs. No wonder why the vast majority of web protocols use ISO 8601
instead of timestamps.
* Even MySQL internally uses ISO 8601 strings to store datetime fields
* This solution requires to write unsupported sqlite code: there is no
"timestamp" datatype in sqlite3, so you implicitely rely on sqlite3 casting this
to a string. You also rely on the python doing implicit conversions from the
database to datetime objects. The funniest part is that the way Python deals
with this implicit conversion is by storing the datetime object as a "%Y-%m-%d
%H:%M:%S" string in the database (which is by the way, not even standard ISO
8601:2004)! No timestamp anywhere to be seen, even though
this is what is stated in schema.sql... This looks insane to me...
Having explicit and standard conventions at the expense of two additional lines
of code does not seems that insane in comparison to Python's insanity.
python. The funniest part is that they way Python does this implicit conversion
is by internally storing the
|
|
still need to check the function which imports the old database
|
|
* make the shortening function backward compatible to old comments
* fix a bug where the show_user function would always display the current user's
profile
|
