1
0
mirror of https://github.com/Jermolene/TiddlyWiki5 synced 2024-11-06 10:06:19 +00:00
Commit Graph

10 Commits

Author SHA1 Message Date
Jermolene
232eba2f7d Http utilities: add xhr object to callback 2019-04-15 21:07:23 +01:00
Jermolene
7a6213dcbf Update code comment for $tw.utils.http 2018-08-23 13:13:49 +01:00
snlhnk
c05c0d3df6 Module-ize server routes, add static file support and other enhancements(#2679)
* Module-ize server routes and add static file support (#2510)

* Refactor server routes to modules

New module type: serverroute

Caveats: Loading order is not deterministic but this would only matter
if two route modules attempted to use the same path regexp (that would
be silly).

* Add static assets plugin

This plugin allows the node server to fetch static assets in the /assets
directory. I felt that this was a feature that goes above the core
functionality. That is why I added it as a plugin. with the modular
route extensions this was a breeze.

* Add serverroute description to ModuleTypes

* Coding standards tweaks

* Fix filename typo

* Move support for attachments from a plugin into the core

* Missing "else"

* Refactor server handling

* Introduce a new named parameter scheme for commands
* Move the SimpleServer class into it's own module
* Deprecate the --server command because of the unwieldy syntax
* Add a new --listen command using the new syntax

For example:

tiddlywiki mywiki --listen host:0.0.0.0 port:8090

* Add check for unknown parameters

* Add support for multiple basic authentication credentials in a CSV file

Beware: Passwords are stored in plain text. If that's a problem, use an authenticating proxy and the trusted header authentication approach.

* Refactor module locations

* Rename "serverroute" module type to "route"

* Remove support for verifying optional named command parameters

The idea was to be able to flag unknown parameter names, but requiring a command to pre-specify all the parameter names makes it harder for (say) the listen command to be extensible so that plugins can add new optional parameters that they handle. (This is particularly in the context of work in progress to encapsulate authenticators into their own modules).

* Refactor the two authenticators into separate modules and add support for authorization

* Correct mistaken path.join vs. path.resolve

See https://stackoverflow.com/a/39836259

* Docs for the named command parameters

I'd be grateful if anyone with sufficient Windows experience could confirm that the note about double quotes in "NamedCommandParameters" is correct.

* Be consistent about lower case parameter names

* Do the right thing when we have a username but no password

With a username parameter but no password parameter we'll attribute edits to that username, but not require authentication.

* Remove obsolete code

* Add support for requiring authentication without restricting the username

* Refactor authorization checks

* Return read_only status in /status response

* Fix two code typos

* Add basic support for detecting readonly status and avoiding write errors

We now have syncadaptors returning  readonly status and avoid attempting to write to the server if it's going to fail

* Add readonly-styles

We hide editing-related buttons in read only mode

I've made this part of the tiddlyweb plugin but I think a case could be made for putting it into the core.

* Add custom request header as CSRF mitigation

By default we require the header X-Requested-With to be set to TiddlyWiki. Can be overriden by setting csrfdisable to "yes"

See https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Protecting_REST_Services:_Use_of_Custom_Request_Headers

* Add support for HTTPS

* First pass at a route for serving rendered tiddlers

cc @Drakor

* Tweaks to the single tiddler static view

Adding a simple sidebar

* Switch to "dash" separated parameter names

* Typo

* Docs: Update ServerCommand and ListenCommand

* First pass at docs for the new web server stuff

Writing the docs is turning out to be quite an undertaking, much harder than writing the code!

* Get rid of extraneous paragraphs in static renderings

* Rejig anonymous user handling

Now we can support wikis that are read-only for anonymous access, but allow a user to login for read/write access.

* More docs

Slowly getting there...

* Static tiddler rendering: Fix HTML content in page title

* Docs updates

* Fix server command parameter names

Missed off 30ce7ea

* Docs: Missing quotes

* Avoid inadvertent dependency on Node.js > v9.6.0

The listenOptions parameter of the plain HTTP version of CreateServer was only introduced in v9.6.0

cc @Drakor @pmario

* Typo
2018-07-18 16:54:43 +01:00
Jermolene
73e1724fdf Extend $tw.utils.httpRequest() to cope with binary data
The problem was that `this.responseText` crashes for non-text data. We
fix it by letting the client specify which property should be returned.

@ericshulman does this work for you?
2017-03-17 13:41:17 +00:00
Myeongjin
6388f859d1 Add localisable strings for error (#2447)
* Add localisable strings for error

* Update tiddler Transclusion Basic Usage in fr-FR
2016-05-17 21:58:47 +01:00
Myeongjin
8afc1e9354 Add localisable strings (#2438)
* Add localisable string for recursive transclusion error

* Add localisable string for count

* Add localisable strings for syncer
2016-05-12 08:44:28 -06:00
Jermolene
a204784c0c Limited implementation of external text tiddlers in the browser
Triggered by the discussion in #1917
2015-08-29 16:33:04 +01:00
Jermolene
e2046ce4ff Treat HTTP 201 response code as success 2014-09-24 16:19:23 +02:00
Jermolene
70a120d4a6 Expand the logging mechanism to support alerts overlaid on the main screen
Now we get decent visual indication of sync errors, for instance. Still
work to do to coalesce alerts so that the screen doesn’t fill up with
them after an interval. And probably we should add a button to clear
all alerts.
2014-02-14 07:53:41 +00:00
Jeremy Ruston
dbde2bf23b Started refactoring TiddlyWeb syncer into generic syncer + TiddlyWeb adaptor
The refactored plugin is `tiddlyweb2` for the moment. The idea is to be
able to use the same syncer with a different adaptor for syncing
changes to the local file system.
2013-03-17 15:28:49 +00:00