Question

This starts out as a question - "Can TWiki do this?" - and, if the answer is "No", becomes a suggestion.

Q: is there any way to add text to a twiki page using the HTTP GET method, rather than the HTTP POST method?

E.g. http://twiki.org/cgi-bin/save/Main/AndyGlew?append&text=some-URL

Q: is there any reason why GET would be less secure than POST? Yes, it's easier to script a GET than a POST, but not much; I doubt enough to make DOS significantly different.

1. e. is there any reason why I should not do this?

Here's why: I would like to create a button in my favorite browser (FireFox), as well as in other browsers (Internet Explorer, etc.) that takes the URI of the page that is currently being visited and posts it on a wiki page.

I find that I have been doing cut-and-paste - copying the URI from the browser address bar, and pasting it into a twiki page - far too often. I want to automate the process. And I would also like to encourage others in my team to do the same, by providing the same function to them in an easy to use form.

I.e. I want to provide a twiki based bookmark sharing facility. I suppose that it is inspired by del.icio.us, although more in the negative: del.icio.us provides only a fixed database entry for saved URLs, and does not provide a way to organize them hierarchically, or to add arbitrary text explaining why you might want to click on a link. Tags help, and I certainly do not want to give up tag functionality; but wikis work best for sharing text and commentary, organizing data, etc.

(Heck, I'd love to have a button that saved both to del.icio.us and to my twiki page of links. But that's dreaming, for now.)

I can fairly easily automate the process in FireFox by writing a plugin. Possibly ditto for IE, although I have never written much for IE. But I am probably not going to do so for the other browsers in use, etc.

Thinking about this, a friend suggested that I look at "bookmarklets". These are javascript:some_js_function() URIs, as seem to be supported by many browsers. Such javascript URI bookmarklets can be placed in the browser's bookmarks or favorites, and possibly on some browser toolbars. That seems to be close enough to a button that is usable on a lot of browsers to me.

PROBLEM: javascript can't use the Http POST protocol. (You can get close using XMLHttpRequest, but restrictions on cross-site-scripting get in the way.)

TWiki seems to use POST to accomplish all TWiki text addition: editing a twiki page, adding text via a comment, etc. This seems to make it impossible to use a javascript bookmark to add text to a twiki page.

Q: am I missing something? Is there some existing TWiki tool that uses GET to add text to a twiki page?

Obviously, it would be very simple to extend one of the twiki tools to add text via GET as well as POST. This appears to be a standard practice with many websites.

Q: is there a security hole that I do not understand here?

• Obviously, a bad guy can script, from the Perl or the like, both GET and POST - so it is not a problem from the pointof view of automated attacks.

• The only possiblity that I can imagine is that GET can be invoked implicitly, e.g. via a redirect or a link that is clicked on, whereas POST requires a form to be filled in on a normal web page.

A possible minor tweak:

I would be happy enough if I could hit the button, and arrive at a twiki page that contains something like a COMMENT form, pre-filled-in with the URL.

Q: is there any way to pre-fill-in the text for a TWiki form, via parameters on the GET URI?

This is how del.icio.us's bookmarklet works for IE:

http://del.icio.us/glew?url=http%3A%2F%2Ftwiki.org%2F;title=TWiki%20-%20Enterprise%20Collaboration%20Platform%20%26%20Wiki;v=4

The bookmarklet: javascript:location.href='http://del.icio.us/post?v=4;url='+encodeURIComponent(location.href)+';title='+encodeURIComponent(document.title)

Environment

-- AndyGlew - 09 Aug 2006

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

Furtherexperimentation gets me much of the way there:

E.g. https://twiki.pdx.intel.com/archfut/bin/edit/Users/AndyGlew/NewItem?text=foobar

Apparently TWiki's edit script accepts command line parameters (?/& in the URL) that fill in various textareas of forms. So far I have only been able to get this to work for new pages, but that may be enough.

(Ironically, I only observed this because I added too much text to the Support question textarea, which my proxy truncated, producing an error that showed me the URL with the & parameter. I think this indicates a TWiki bug - it allows too much stuff to be created using GET on the Support question textarea - most references indicate a small value desired if being placed into a URL.)

So, I am working toward using an URL that invokes TWiki edit, passing form parameters on the command line. Using a template that contains a form that invokes POST (save, or the like) to some other page.

Ugly.

-- AndyGlew - 09 Aug 2006

http://twiki.org/cgi-bin/edit/Sandbox/NewItem?text=foobar for twiki site

-- AndyGlew - 09 Aug 2006

GET and POST are just different ways of getting to the same script. The difference is that a GET passes parameters in the URL, whereas a POST uses an attached data form to pass parameters. For example, here's three different ways of doing the same thing (click the buttons, then view the page source to see what they do)

Snort me

You will now click a link

The difference is that parameters to GET are limited to a server-defined size (usually <1024 bytes) so GET can't be used with big parameters.

TWiki scripts work with the same parameters in POST or GET. See TWikiScripts for documentation of the parameters accepted by the scripts.

-- CrawfordCurrie - 12 Aug 2006

The other big difference between GET and POST is that JavaScript can generate arbitrary GET URLs, but JavaScript cannot (to the best of my knowledge) generate a POST to an arbitrary website.

-- AndyGlew - 17 Aug 2006

Well, I can't see, in TWikiScripts, any way using the existing scripts to get any data from the GET URL params into a twiki page.

Actually, that is not true. edit ... ?text=foo creates foo as the new text. But I cannot see any other way, any way that is better behaved than replacing all of the wiki page.

E.g. I keep hoping that there is a way to pass a default value to be placed in the comment textarea of a %COMMENT% form. But nothing seems to work.

But... I will take what you say, Crawford, as permission to modify one of the twiki scripts, probably via a plugin, to take a parameter and place it either as the default value of a form, or to add to a page directly.

Prime candidates:

1. %COMMENT% - adding a default value to CommentPlugin
2. creating an "append" action for the save script.
   • plus maybe an append script or set of pages, to handle the possibility of an append attempt while a lock is outstanding.

You say "TWiki scripts work with the same parameters in POST or GET.". However, reading the twiki source code I am reasonably certain that this is not the case.

-- AndyGlew - 17 Aug 2006

Got it - or, at least, gotit at the level of raw HTML forms, but not in the nice way that %COMMENT%, etc., provide:

First, create a JavaScript URL, and place it in your Bookmarks or links or favorites toolbar - works on both IE and FireFox:

javascript:location.href='http://twiki.org/cgi-bin/view/Support/PostingUsingGETnotPOST?url='+encodeURIComponent(location.href)+';title='+encodeURIComponent(document.title)

<form method="post" action="http://twiki.org/cgi-bin/save/Support/PostingUsingGETnotPOST" enctype="application/x-www-form-urlencoded" name="below0">
<table><tr valign="middle"><td><textarea  rows="3" cols="70" name="comment" wrap="soft" onfocus="if(this.value=='')this.value=''" onblur="if(this.value=='')this.value=''">Here is an URL that got pre-filled in from the url= parameter: %URLPARAM{"url"}%</textarea></td><td><input  type="submit" value="Add comment" /></td></tr></table>
<input type="hidden" name="comment_action" value="save" /><input type="hidden" name="comment_type" value="below" /><input type="hidden" name="comment_index" value="0" /><div></div>
</form> 

as in the following, which will pre-fill in a %COMMENT% for the current page, and append to the place where the other comments go.

Here is an URL that got pre-filled in from the url= parameter:

http://twiki.org/cgi-bin/view/Support/PostingUsingGETnotPOST?url=foo

(The usual minor badness if there are two comments in a page - as there are here.)

-- AndyGlew - 17 Aug 2006

Here are some URLs that got added by the form above, but which were added using the "below" COMMENT option. Rearranged by hand, and changed the form to use threadmode subsequently.

• Here is an URL that got pre-filled in from the url= parameter: bar - url=bar on the command line -- AndyGlew - 16 Aug 2006 - 21:03
• Here is an URL that got pre-filled in from the url= parameter: http://www.google.com
  • this one was created from the FireFox Bookmarks toolbar
  • I went to google, clicked the link button on the toolbar
  • google added a bit more crap to the link, which I edited out -- AndyGlew - 16 Aug 2006 - 20:54
• Here is an URL that got pre-filled in from the url= parameter: foo - and now you can add comments, and you have a bookmark on a wiki page, which you can create by clicking on a bookmark button in your browser. -- AndyGlew - 16 Aug 2006 - 20:49

Here is an URL that got pre-filled in from the url= parameter: threadmode - another test from the address box, except this time I changed the comment/form parameter to threadmode from below, changing the position where stuff gets added.

-- AndyGlew - 17 Aug 2006

Here is an URL that got pre-filled in from the url= parameter: http://www.c2.com/ - yet another test from the FireFox bookmark line; this time I left the extra stuff on the URL there

-- AndyGlew - 17 Aug 2006

Here is an URL that got pre-filled in from the url= parameter: http://www.intel.com/ - this one got added from a javascript bookmarklet that was placed in an Internet Explorer Favorite in the IE Links toolbar.

-- AndyGlew - 17 Aug 2006

Obviously, some cleanups need to be done, including:

• it sucks to have to place the raw form HTML in a twiki page. Need to extend twiki's %COMMENT% to accept default text.
  • might be able to do this using a COMMENT prompt template.
• obviously want to change the "Add comment" button to "Add bookmark"... heck, I'll do that directly in the form... should be done
• might be nice to generalize this to a multipart form - bookmark name, URL, comment, tags, etc.
  • but then again, twiki text allows you to do this. a form would just encourage the fields to be filled in
  • might be nice to have a generic form receiver, that places all form fields into a reasonable twiki format
  • needs a new plugin (and I stil haven't coded a clean twiki plugin)

-- AndyGlew - 17 Aug 2006

-- AndyGlew - 17 Aug 2006

would like to be able to distribute a bookmark to multiple bookmark pages simultaneously - multicast.

• maybe a pulldown list of usual bookmark sites - delicious, my internal blog, etc.
  • in case you are wondering, why have multiple bookmark sites - it arises, unfortunately, because URLs on my company Intranet are sometimes themselves secret, not to be posted on a public site such as delicious.
  • for that matter, would like to be able to pre-fill in a delicious form as well as the twiki stuff.
• for that matter, would also like to be able to email - I often find myself

-- AndyGlew - 17 Aug 2006

Crosslink to CommentPluginDev - since I really want to figure out how to call CommentPlugin, not do the ugly raw form HTML. I hope that I can accomplish this by modifying a CommentPlugin template.

-- AndyGlew - 17 Aug 2006

FYI, I have, on my company intranet twikisite, created

1. a nice tutorial/example of how to set this up b. plus a stripped down GlewBookmarkWiki page that I use.

It would be nice to be able to make the bookmark/favorite icon draggable to the toolbar.

-- AndyGlew - 17 Aug 2006

Since PostingUsingGETnotPOST is not really an appropriate name, I'll create a similar page BookmarkSharingWithTWiki. Although that may be an equally inappropriate name.

-- AndyGlew - 17 Aug 2006