Open
Bug 242974
Opened 20 years ago
Updated 2 years ago
problem submitting form in html mail for forms with method="post"
Categories
(Thunderbird :: General, enhancement)
Thunderbird
General
Tracking
(Not tracked)
NEW
People
(Reporter: mcoarr, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040229 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040229 Firefox/0.8.0+
When I receive html mail in thunderbird that has an html form, the form
submission is not passed correctly if the form uses method=post.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1•20 years ago
|
||
can't find an earlier report of this for Thunderbird, but I might have missed
it. obviously tricky for Thunderbird to do POST form submission because it's not
a browser.
Assignee: sspitzer → mscott
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → General
Ever confirmed: true
OS: Linux → All
Product: MailNews → Thunderbird
Hardware: PC → All
Version: Trunk → unspecified
Comment 2•20 years ago
|
||
*** Bug 247208 has been marked as a duplicate of this bug. ***
Would it be possible to convert POST to GET? I know some foms would be broken
due to that, but it wouldn't be any more broken than the current version but
would fix for some forms.
(this is an annoyance in trying to convert from Mozilla to Thunderbird. I have
not tried Outlook behavior for this to see if it allows form POST)
Also, since this is a regression from the behavior of the Mozilla Suite that
this will replace in the future, I believe this is a minor bug, not an enhancement.
Comment 4•20 years ago
|
||
dup of bug 218976 ?
Comment 5•20 years ago
|
||
Darin, any thoughts on this, or on who might have an idea? Would it be very hard
or at all possible for tbird to handle the form submit itself?
Comment 6•20 years ago
|
||
I don't know the form submission code all that well, but it seems odd to me that
it is not being invoked already by Gecko. Perhaps some debugging would reveal
the problem.
Comment 7•20 years ago
|
||
(In reply to comment #6)
> but it seems odd to me that
> it is not being invoked already by Gecko.
I'm sure that's because gecko never even gets a chance. http is not an exposed
protocol for thunderbird. when you click on an http url, the uriloader sends it
straight to the OS. We don't do anything with it.
Comment 8•20 years ago
|
||
yes, I should have said that when we launch the external browser, we can only
pass in a url, and the form data doesn't get passed into the external browser.
And since we can't control the external browser, it seems that the only way to
get this working from tbird is to have tbird do it itself, via gecko.
Comment 9•20 years ago
|
||
oh, right... of course. what is the ideal result? are you hoping to have tbird
download the resulting html file and then have the browser load that html file
from the local filesystem? (using file:// URLs instead of http:// URLs has JS
security problems since the security principal of the page is no longer that of
the website.) or do you want tbird to load the result of the form post into
some sort of window within tbird? it might be neat to show the results of a
form post in a popup window or something. do any other mailers support html
form post?
Comment 10•20 years ago
|
||
I'm not sure what the ideal result would be - if it doesn't open too big a can
of worms, I think *not* launching a browser would be nice, but we're mostly
interested in being able to get the submit itself working.
We don't know if any other html mailers support this - we're pretty sure OE
doesn't, and I suspect neither does Outlook. I'd bet Eudora doesn't either...
Comment 11•20 years ago
|
||
If I understand correctly, we'd need a mechanism for thunderbird to get a crack
at the url, somehow figure out if the http url was a form post (I assume that's
not hard). If it's not a form post, we'd need to kick it back to the uri loader;
otherwise, we'd need to run the url through gecko and display the results in a
little wrapper html window. How hard does all this sound?
Comment 12•20 years ago
|
||
lot's of unknowns for me.. i couldn't say how hard it would be to implement it :-/
Comment 13•20 years ago
|
||
well this is a dupe of 218976 - my fault for missing that. but now you guys have
started discussing here, I guess this should be duped backwards.
Comment 14•20 years ago
|
||
*** Bug 218976 has been marked as a duplicate of this bug. ***
Comment 15•20 years ago
|
||
With the new RSS reader in Thuderbird this is going to become increasingly
requested. e.g. if you read Slashdot through its RSS feed then when the stories
are displayed in Thunderbird it is not possible to login to your account and
therefore have your default filter settings on comments. For the whole login
process to work inside Thuderbird would require cookies too.
So the ideal solution would be. Submit a POST request and reload the resulting
page within the same window in Thunderbird. Accept the cookie and remain logged
into slashdot so that when you read the next story it remembers who you are.
Comment 16•20 years ago
|
||
This is of particular interest to me as this is my main interface to LiveJournal
comments. Perhaps LJ can look into doing this as a GET.
Comment 17•20 years ago
|
||
The probem seems to be within Thunderbird's handling of the form. When I attempt
to submit the form from Thunderbird, it only sends the URL to the browser,
without any other information.
Method for testing:
Create a shell script that prints all inputs:
#!/bin/bash
echo $*>>test.out
Change Thunderbird to invoke script for all e-mail:
user_pref("network.protocol-handler.app.http", "/path/to/script/file.sh");
Attempt to submit form, receive:
http://www.example.url/form_action_url.html
Expect:
http://www.example.url/form_action_url.html?form_data=test&other_stuff=stuff
(Or something similar, where the data is embedded into URL.)
This could fix the problem for websites that would allow GET requests.
Comment 18•20 years ago
|
||
>Expect:
>http://www.example.url/form_action_url.html?form_data=test&other_stuff=stuff
>(Or something similar, where the data is embedded into URL.)
why do you expect that, for a POST method? this url would correspond to a GET
method.
Comment 19•20 years ago
|
||
(In reply to comment #18)
> >Expect:
> >http://www.example.url/form_action_url.html?form_data=test&other_stuff=stuff
> >(Or something similar, where the data is embedded into URL.)
>
> why do you expect that, for a POST method? this url would correspond to a GET
> method.
That would be a solution that would be the least-surprise to a user attempting
to do a submission from the form within Thunderbird. Creation of new embeded
Gecko window would be a surprise for user because it would not be their browser.
(ie. They can't continue browsing, change any information or have their extensions)
That is unfortunately not a solution that allows for full conformance to the
request of the HTML. But from my understanding, it would be impossible to
conform to the HTML and yet not surprise the user. (Unless there's some other
method of passing the URL other than command line paramater - ie. what the suite
was doing and probably what Outlook+IE does)
Comment 20•20 years ago
|
||
I think the best way for the end-user is going to be to have Thunderbird
interact with Firefox to post the form, but how practical is the interaction? Of
course, there's going to be the problem of people who aren't using Firefox
(There's bound to be one or two!). How does OE -> Firefox handle? I can't test
it, as I don't have OE on any of my machines anymore, but I'll see if I can get
it reinstalled on one for testing. No idea on the other platforms though.
The other solution is as proposed, have Thunderbird process it internally in a
Gecko window (preview window / new window?), and handle it from there. But that
may get confusing to users, and leave them open to browing through the TB
window, which would be undesirable...
Not sure how to proceed on this one, and I haven't a clue where to start on it
myself personally. It also doesn't say anything about other operating systems.
Perhaps some sort of internal XUL document format to be passed to Firefox if
detected?
(Sorry if this lot's just useless wild stabbing, just looking to try and give
ideas.)
Comment 21•20 years ago
|
||
I think the best way for the end-user is going to be to have Thunderbird
interact with Firefox to post the form, but how practical is the interaction? Of
course, there's going to be the problem of people who aren't using Firefox
(There's bound to be one or two!). How does OE -> Firefox handle? I can't test
it, as I don't have OE on any of my machines anymore, but I'll see if I can get
it reinstalled on one for testing. No idea on the other platforms though.
The other solution is as proposed, have Thunderbird process it internally in a
Gecko window (preview window / new window?), and handle it from there. But that
may get confusing to users, and leave them open to browing through the TB
window, which would be undesirable...
Not sure how to proceed on this one, and I haven't a clue where to start on it
myself personally. It also doesn't say anything about other operating systems.
Perhaps some sort of internal XUL document format to be passed to Firefox if
detected?
(Sorry if this lot's just useless wild stabbing, just looking to try and give
ideas.)
Comment 22•20 years ago
|
||
I just downloaded Tbird 1.0 to try it out and it apparently still has this bug.
I'd really like to switch to Thunderbird, but I won't until this bug is fixed.
Is anyone working on it?
Comment 23•20 years ago
|
||
Does the GRE have an equivalent of DDE? I have a feeling that's the way OE/IE do
it... but it's how to get the data across. Tempfiles are messy and can be
unreliable, but a cross-platform implementation needs sorting out to solve the
issue.
Unfortunately, I've no idea how to do it - hacking the internals of Mozilla
isn't my forté yet :(
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Updated•19 years ago
|
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Comment 24•19 years ago
|
||
(In reply to comment #20)
> I think the best way for the end-user is going to be to have Thunderbird
> interact with Firefox to post the form, but how practical is the interaction?
Of
> course, there's going to be the problem of people who aren't using Firefox
> (There's bound to be one or two!). How does OE -> Firefox handle? I can't test
> it, as I don't have OE on any of my machines anymore, but I'll see if I can
get
> it reinstalled on one for testing. No idea on the other platforms though.
> The other solution is as proposed, have Thunderbird process it internally in a
> Gecko window (preview window / new window?), and handle it from there. But
that
> may get confusing to users, and leave them open to browing through the TB
> window, which would be undesirable...
> Not sure how to proceed on this one, and I haven't a clue where to start on it
> myself personally. It also doesn't say anything about other operating systems.
> Perhaps some sort of internal XUL document format to be passed to Firefox if
> detected?
> (Sorry if this lot's just useless wild stabbing, just looking to try and give
> ideas.)
OE/Firefox doesn't works with POST, like Thunderbird, but OE/IE works fine.
Comment 25•19 years ago
|
||
*** Bug 301535 has been marked as a duplicate of this bug. ***
Comment 26•19 years ago
|
||
I have no problems POSTing forms with Mozilla mail. Why the problem with
Thunderbird? It doesn't seem to me that it should be that hard to get right.
I find it interesting that there was only one vote for this bug - is no-one
using email creatively?
Comment 27•19 years ago
|
||
>I have no problems POSTing forms with Mozilla mail. Why the problem with
>Thunderbird? It doesn't seem to me that it should be that hard to get right.
We're not talking about Mozilla mail.
Unilke the Mozilla Suite, which has an e-mail client and a web browser in one
application, Firefox and Thunderbird are separate applications. There doesn't
exist (to my knowledge) a standard cross-platform method of passing large
amounts of data between two programs.
In Firefox, all we can really do at this point is pass a URL to Firefox via the
command line. We don't have any fancy interprocess communication available yet.
(See Comment 8).
Comment 28•19 years ago
|
||
(In reply to comment #27)
>There doesn't
> exist (to my knowledge) a standard cross-platform method of passing large
> amounts of data between two programs.
>
> In Firefox, all we can really do at this point is pass a URL to Firefox via the
> command line. We don't have any fancy interprocess communication available yet.
> (See Comment 8).
Yep, I can see that could be a problem :-)
How about generating a temp file with some javascript that when that is opened
in the browser forwards the POST data? Some similar trickery should be workable.
gen - post12345.html, firefox.exe %tmpdir%/post12345.html
Comment 29•19 years ago
|
||
Following on from my suggestion on generating a tempfile, and also picking up
(again) on Paul's comment regarding inter app communication, it struck me that a
browser does indeed provide such a protocol.
Rather than generating a tempfile, the invoked app could be:
firefox.exe http://localhost:<thunderbirdport>/post1234.html
...and generate the data internally rather than writing to an external file.
The port could be created dynamically and closed after serving up the content.
Comment 30•19 years ago
|
||
What about to write (for temporary use) an extension, that saves a mail with
post form and launching FireFox or IE to process the file?
Or other idea:
Changing submit buttons (that in post method forms) in mail to such view:
<input type=button value='Submit' onclick='submitform();'>
And a function is:
function submitform()
{
popup = window.open('', 'result');
popup.document.open();
popup.document.writeln('<html>');
popup.document.writeln('<body onload=\"mailform.submit()\">');
popup.document.writeln('<form name=\"mailform\" action=\"somehostandpath\"
method=\"POST\">');
popup.document.writeln('FORM');//There is content of form in the mail
popup.document.writeln('</form>');
popup.document.writeln('</body>');
popup.document.close();
popup.focus();
}
I think it is good idea for a while.
Comment 31•19 years ago
|
||
(In reply to comment #30)
> Or other idea:
> Changing submit buttons (that in post method forms) in mail to such view:
> <input type=button value='Submit' onclick='submitform();'>
>
> And a function is:
> [code]
> I think it is good idea for a while.
Not a bad idea - but what about having Thunderbird process the the POST request,
save the result, and passing the request via a command to FF?
For example:
1. Thunderbird recieves e-mail with form enclosed.
2. User fills out form, clicks submit button.
3. Thunderbird processes this internally, saving the resulting data to a file.
4. Firefox is called, with an "IPC command" switch, advising it of where the
data would normally be sent to, and the returned data from the site. (e.g.
firefox.exe /IPCcommand:ProcessForm /data:c:\temp\data.tmp
/site:http://www.somesite.com/formprocess.php)
5. Firefox loads, shows existing site in URL bar (but with note to show URL
encoded form - perhaps a red bar, like the yellow one for secure, and/or perhaps
asking the user before confirming), displays data from the TB post, and the user
can then continue to navigate. Any appropriate cookies would also need to get
sent across though in the process.
This approach however has a couple of issues:
1. Possibility of phishing-type attacks, with maliciously constructed forms
2. Possible spam abuse
3. The data processed by Thunderbird wouldn't have the cookies for Firefox.
Another possible approach:
Not a bad idea - but what about having Thunderbird process the the POST request,
save the result, and passing the request via a command to FF?
For example:
1. Thunderbird recieves e-mail with form enclosed.
2. User fills out form, clicks submit button.
3. Thunderbird sends the form to a file with the form data filled in.
4. Firefox is called, with an "IPC command" switch, advising it of where the
data is to be be sent to (e.g. firefox.exe /IPCcommand:ProcessForm
/data:c:\temp\data.tmp).
5. Firefox loads, shows existing site in URL bar (but with note to show URL
encoded form - perhaps a red bar, like the yellow one for secure, and/or perhaps
asking the user before confirming), displays data from the TB post, and the user
can then continue to navigate. All relevant cookies are already present.
Approach 2 is less likely to be abused, but will need some consideration before
continuing.
Comment 32•19 years ago
|
||
You don't want to save the form submission results to a local file and render
that in a browser because that would be letting remote scripts have access to
your filesystem. Instead, the approach of having thunderbird open a server
socket on a random localhost port sounds much more reasonable from a security
point of view.
Comment 33•19 years ago
|
||
(In reply to comment #32)
> You don't want to save the form submission results to a local file and render
> that in a browser because that would be letting remote scripts have access to
> your filesystem. Instead, the approach of having thunderbird open a server
> socket on a random localhost port sounds much more reasonable from a security
> point of view.
I must admit, it does seem a good idea. Either that, or some sort of standard
Gecko port? Either way, it is better than actual local files - basically a pipe
between the applications.
However, I'd still be concerned on the FF pickup side - it'd have to be
carefully done to avoid abuse.
Comment 34•19 years ago
|
||
Socket solving sounds good, but is it a bit complex? Or will the user system
stable during opening server socket? I don't know much about this, but I feel,
that there will be some incompatibility with different systems.
JavaScript is platform independent and doesn't need something extra. TB can
hadle it. And it's security is defines by security of JavaScript itself.
JavaScript in addition is compatible with IE, so it can provide both TB->IE
and TB->FF links (or any other), when the OE can work only with IE.
Any spam or abuse issues can be hadled too, we can make, that FF will show all
the data to user before posting it.
Comment 35•19 years ago
|
||
oooh yes, I like that!
Feedback the data to be sent to the user and ask for POST confirmation. This
"confirmation" page would of course be generated in the same way as the
"auto-forwarder" would have been.
This could eventually be a preference in Thunderbird: "Display POST
confirmation" or somesuch.
So.. is there a consensus on the firefox.exe
http://localhost:dynamicport/magic.html approach?
If so I guess we just need to increase the vote count.
Comment 36•19 years ago
|
||
I am novice here... and how can we get this bug fixed? Only by increasing
votes? Or write the code ourself?
PS: Just for etiquette: my name is Lalov Sergey.
Comment 37•19 years ago
|
||
(In reply to comment #35)
> This could eventually be a preference in Thunderbird: "Display POST
> confirmation" or somesuch.
I'd recommend having that on the FF side rather than the TB side. Two reasons
behind this:
1. It stops other rogue programs attempting to exploit this (pro-active security)
2. It may allow for cross-program compatibility - i.e. (I know it's not my
personal choice, but a lot of people use it) Outlook/OE perhaps on the 'doze
side, or whatever else.
The approach sounds good though. I wouldn't use a magic HTML page, just a local
host and socket, which they can use IPC-style.
Comment 38•19 years ago
|
||
Yep, rick, I think that is pretty much what I meant anyway...
The "magic.html" was just to indicate a file reference at the end of the
socket.. not a physical file.
And I had assumed that the confirmation form would be generated from TB but
displayed in FF/IE whetever.
Comment 39•19 years ago
|
||
(In reply to comment #37)
> I'd recommend having that on the FF side rather than the TB side. Two reasons
> behind this:
> 1. It stops other rogue programs attempting to exploit this (pro-active
security)
> 2. It may allow for cross-program compatibility - i.e. (I know it's not my
> personal choice, but a lot of people use it) Outlook/OE perhaps on the 'doze
> side, or whatever else.
1.The problem is only with TB, and TB should handle this, not to shift it to
FF. FF doesn't have to care about TB bugs. And IPC method is dangerous too,
any other rogue problem can use this. With generating form in TB we can avoid
the most of atacks by generating all the script just in a 'onclick' property
with 'this' reference to form, so no other form will submit. And with user
confirmation we can absolutely protect the user.
2.It provides cross-program compatibility, but from other side, TB can work
with any browser. And those, who use Outlook/OE uses IE too, so they work fine
with such forms. And when OE user will want to use TB, he will have to install
FF too for properly program work. It is uncomfortable.
If you want FF to handle this bug, maybe you will like other idea: plugin the
FF engine into TB, so the mail will be browsed by FF and POST forms will work
fine. Microsoft provides such engine for IE, so one can use it in his own
programs.
Comment 40•19 years ago
|
||
(In reply to comment #39)
> 1.The problem is only with TB, and TB should handle this, not to shift it to
> FF. FF doesn't have to care about TB bugs. And IPC method is dangerous too,
> any other rogue problem can use this. With generating form in TB we can avoid
> the most of atacks by generating all the script just in a 'onclick' property
> with 'this' reference to form, so no other form will submit. And with user
> confirmation we can absolutely protect the user.
Not true. Outlook Express and the like also attempt to enter forms with
method=POST. It doesn't work when it sends it to FF either. I'm still not sure
what method OE/IE uses though. Regarding FF not having to care about TB bugs -
technically, that may be right, but if we want the user base, we have to fix the
problems that are causing issues for people. In this case, it's the fact that
users can't use HTML forms properly that use POST. They don't care which member
of which camp fixes what. A typical example is LiveJournal - it sends out
comment fields with a post button, which appear to function perfectly in TB,
only to fail in FF as the POSTDATA isn't passed.
> 2.It provides cross-program compatibility, but from other side, TB can work
> with any browser. And those, who use Outlook/OE uses IE too, so they work fine
> with such forms. And when OE user will want to use TB, he will have to install
> FF too for properly program work. It is uncomfortable.
The problem here is that you can't post forms from TB or anything else into FF
at the moment.
> If you want FF to handle this bug, maybe you will like other idea: plugin the
> FF engine into TB, so the mail will be browsed by FF and POST forms will work
> fine. Microsoft provides such engine for IE, so one can use it in his own
> programs.
We've thought about that. The Gecko engine is already built-in to TB, but apart
from the fact it'll hold no relevant cookies etc for the user, it provides much
less flexibility - users will generally want to continue browsing after dealing
with such a form, and TB is hardly the ideal browsing environment - that's not
what it's designed for. FF browses, TB reads mail. I think it should be kept
that way, and the interoperability improved.
The magic.html file approach is seeming more realistic. Yes, if someone wished
to create an attack this way, it's theoretically possible, but if they were so
determined, it's not that hard to set one up manually with a HTML file. I'd
definately want confirmation though with a detailed dialogue box, showing the
site it's being sent to.
I'd put checks in though to avoid the likes of PayPal phishing, because users
WILL fall into that trap, but I'm not sure how that'd go. Mind you, TB looks
like it's getting those identification capabilities already.
Comment 41•19 years ago
|
||
Hm. Okay, some other idea:
Can whe translate a html mail into the FF by command line parametr? Ofcorse,
the mail should be coded before (in Base64, for example). So no file is
needed. And ofcorse FF shoul be modifed.
Comment 42•19 years ago
|
||
(In reply to comment #41)
> Hm. Okay, some other idea:
> Can whe translate a html mail into the FF by command line parametr? Ofcorse,
> the mail should be coded before (in Base64, for example). So no file is
> needed. And ofcorse FF shoul be modifed.
Interesting idea - but do command lines have limitations per O/S? My primary
concern would be that not all of the form data would be transferred on large
forms, hence the idea of a tempfile.
Anyone got any ideas of command line lengths?
Comment 43•19 years ago
|
||
http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx covers most of
the ones you'll come across on Windows, but it basically boils down to the 2048
limit for ShellExecute.
Generally speaking, command-lines are very limited in size, and it would be wise
to not try and rely on it being long enough (plus it would create some odd bugs
if it only failed for some forms).
Comment 44•19 years ago
|
||
(In reply to comment #43)
> Generally speaking, command-lines are very limited in size, and it would be wise
> to not try and rely on it being long enough (plus it would create some odd bugs
> if it only failed for some forms).
Agreed. Command lines are less than ideal.
If we have no direct IPC, we have files as a possibility (with FF confirmation).
Have we any other options?
Comment 45•19 years ago
|
||
Temporary files and a mini-webserver-thing (comment 29) are the only options I
know of which would not require modifications to Firefox to function. I think
trying to do the actual post within Thunderbird is just not going to work.
Comment 46•19 years ago
|
||
(In reply to comment #45)
> Temporary files and a mini-webserver-thing (comment 29) are the only options I
> know of which would not require modifications to Firefox to function. I think
> trying to do the actual post within Thunderbird is just not going to work.
To be honest, I'd be more in favour of that option, as it removes potential file
issues. People could still write a program to feed the information in, but if it
came to that, they could probably far more easily fashion a direct request. I
wouldn't consider security too much of an issue.
If this works, it could also pave the way for more TB->Firefox interaction, as
well as Sunbird and the like.
Comment 47•19 years ago
|
||
Hm. Okay, some other idea:
To write a CGI (or something like this). TB translates to a FF a link like
firefox.exe "tbroot\someutil.exe -postmailno12345"
Then FF executes someutil.exe, which prints out all the needed data, and FF
recives it.
Comment 48•19 years ago
|
||
(In reply to comment #47)
> Hm. Okay, some other idea:
> To write a CGI (or something like this). TB translates to a FF a link like
> firefox.exe "tbroot\someutil.exe -postmailno12345"
> Then FF executes someutil.exe, which prints out all the needed data, and FF
> recives it.
..errmm... what is the discussion about?
FF already supports http protocol from command-line. just use it (as per my #29
comment)
Are there any TB developers out there who want to progress this? I think this
is quite an interesting bug to fix, unfortunately I do not have time (or
immediate TB experience) to do myself.
Comment 49•19 years ago
|
||
(In reply to comment #48)
> FF already supports http protocol from command-line. just use it (as per my #29
> comment)
The command line may not be suitable, that's the issue. There's limits on the
lengths, and could lead to other possible weirdness. Firefox also doesn't
support POST from the command line, which led to this initial problem.
It's going to be my first real bit of FF/TB hacking, but I'm willing to have a
go as soon as I've finished brushing up on my C++.
Re the CGI-type program, to be honest, it'd just be an additional step - if we
were going to do that, we may as well use a magic html file to do it.
We may actually be able to do messily temporarily via a created HTML file with
the values pre-filled in, using Javascript to post it automatically, with user
confirmation (and values displayed perhaps?), hooking in when there's a POST
form available in the current page. (We'd also have to check for multiple forms
too.) That would be the easiest way with the magic.html file.
Comment 50•19 years ago
|
||
(In reply to comment #49)
> (In reply to comment #48)
> > FF already supports http protocol from command-line. just use it (as per my #29
> > comment)
>
> The command line may not be suitable, that's the issue. There's limits on the
> lengths, and could lead to other possible weirdness. Firefox also doesn't
> support POST from the command line, which led to this initial problem.
>
>
You should read #29 again. There is no problem with commandline length, the
idea is to use the url to redirect the request back to TB achieved using the
protocol "http://localhost:<dynamic port>/maginc.html" - TB will act as a
webserver in this case serving the contents of the "magic.html" or whatever name
is given to generate the relevant file, and yes, the generated file would have
the values filled in and an "onLoad" bit of javascript used to submit the form.
Comment 51•19 years ago
|
||
> You should read #29 again. There is no problem with commandline length, the
> idea is to use the url to redirect the request back to TB achieved using the
> protocol "http://localhost:<dynamic port>/maginc.html" - TB will act as a
> webserver in this case serving the contents of the "magic.html" or whatever name
> is given to generate the relevant file, and yes, the generated file would have
> the values filled in and an "onLoad" bit of javascript used to submit the form.
Sorry, may have gone off on a tangent there. I agreed with that in principle,
and it's better than creating tempfiles all over the place. Does this sound
viable? Creating the socket shouldn't be a huge problem in theory.
So this boils down to a few steps.
1. Scan e-mail when HTML view is enabled for form action="post".
2. Rewrite post URL to indicate an internal chrome link?
3. Use chrome to create magic HTML in memory?
4. Send FF the command line to connect to TB
5. FF loads the link via standard HTTP link
6. FF loads page with pre-filled values, perhaps with a small bit of explanation
("Mozilla Thunderbird is transferring your form values...") or possibly a
description of the send form values?
7. FF requests confirmation via onLoad to submit the information
8. FF sends data.
This requires no modifications at all to FF, as it's a standard URL.
Thoughts?
Comment 52•19 years ago
|
||
Yep, spot on I reckon :-)
The socket should probably have a one shot only lifetime, so just name the
"magic.html" with some generated random number "magic_362983.html" and check
against any request made.
Maybe a good idea to give the file a meaningful name to make it clear where its
come from, say "thunderbird_post_362983.html".
Once the data is served then close the socket and free any resource.
Comment 53•19 years ago
|
||
So random port and random filename too for added security? Admittedly, it's not
hugely great for a security measure, but it'll stop most of the script kiddies.
Theoretically, we could do this through pure javascript inside the browser,
extension-style, but I'm not certain. I'd personally prefer to keep it in the
C++ if possible, but it means going in deeper.
Will do some research into the code. The most complicated part is probably
creating the port, and even that shouldn't be too difficult.
Comment 54•19 years ago
|
||
I have one more (crazy) idea: let's prepare in FF some amount of memory with
defined offset (about 100KB), than TB will find firefox.exe process in memory
and will write a post data to that container. Then FF will send it after
submiting by user.
Comment 55•19 years ago
|
||
Processes can't write to each other's memory spaces.
Comment 56•19 years ago
|
||
Yup, with good reason - it'd be horribly insecure. Anything could write to that
space.
'Fraid it was a little crazy ;)
We're continuing discussions offline, and will post more here when I have a
proposal.
Comment 57•19 years ago
|
||
Haven't had time to work more on this :( Will try to fit some in before new year though...
Comment 58•19 years ago
|
||
*** Bug 262721 has been marked as a duplicate of this bug. ***
Comment 59•19 years ago
|
||
I've been trying to work out the best way to tackle this.
So far, my thoughts of the process are as follows:
Check for form presence
Identify any submit buttons, attach javascript intercept within the mail body view to fire external javascript call
When JS call is made:
Identify which form the pressed submit button belongs to
Create blank HTML from template (add basic head/body attributes etc), add automatic form submission to form body (with confirmation on browser side if set as a pref)
Copy form and form contents into HTML file in memory, using hidden values for submission
Tag submit button with an ID matching the name (or a random ID if no name specified for submit button), for javascript auto-submit, printed via javascript to avoid conflict with the noscript submit button
Add noscript option to submit form, for users with no javascript enabled
Open external random port, between set range (prefs?), bound to localhost
Display "Submitting form, please wait" on Thunderbird, blocking access to the rest of it, and fire external URL request to http://localhost:randomport/
On retrieval of form via HTTP from the browser, automatically close port and "Submitting form" dialog
If no response within a set period set in prefs (30 seconds default), automatically close the port and cancel the dialog box. I'd suggest a countdown in the box.
On the browser side:
Load HTML form directly from TB socket
Auto-submit if javascript enabled (with confirmation if it was set in the TB prefs)
"Send e-mail form" button for non-JS enabled browsers
=====
Most of this I can do, but I'm working out how to add the JS intercept to the submit buttons, and how to identify the form in question to grab it's info and values. I'll keep researching, but if anyone can help out on that score, I'd appreciate it.
Looking at the JS function above, there's a possibility of using onclick='submitform(this)' or something similar to help identify it...
Comment 60•18 years ago
|
||
*** Bug 349917 has been marked as a duplicate of this bug. ***
Comment 61•18 years ago
|
||
Why not to use DDE to transmit information from TB into FF? That would be much more straightforward solution for this problem, than creating some special temporary files, javascripts, etc. One problem is, FF currently doesn't support POSTing by DDE message. But it surely can be done. See #267032.
Comment 62•18 years ago
|
||
DDE is also not cross-platform, which poses its own problems. There are, I know, similar systems (in concept if not implementation) on other platforms, but it does make it a trickier solution to use.
Comment 63•18 years ago
|
||
Unfortunately I've not had chance to do this myself. I know it's been a while, but work has killed my spare time off.
I think the method I suggest would work for definite cross platform, albeit not the cleanest of methods in the world. A temporary HTML file may be better and more secure, although then you'd have to figure out how to automatically delete it once it'd been accessed.
Comment 64•18 years ago
|
||
(In reply to comment #15)
> With the new RSS reader in Thuderbird this is going to become increasingly
> requested. e.g. if you read Slashdot through its RSS feed then when the stories
> are displayed in Thunderbird it is not possible to login to your account and
> therefore have your default filter settings on comments. For the whole login
> process to work inside Thuderbird would require cookies too.
>
> So the ideal solution would be. Submit a POST request and reload the resulting
> page within the same window in Thunderbird. Accept the cookie and remain logged
> into slashdot so that when you read the next story it remembers who you are.
Bug 318104 has a discussion about that: [RFE] allow feed article browsing inside thunderbird
As say here with slashdot, but the problem is still there with flickr rss (missing cookies and login ability in TB) and with other multipage feeds ( http://feeds.feedburner.com/GamasutraFeatureArticles or
http://www.escapistmagazine.com/rss.xml ), maybe a best solution to handling post is to have a mini browser inside TB, handling cookies and POST/GET sending with display of the response inside TB.
Updated•17 years ago
|
QA Contact: general
Updated•16 years ago
|
Assignee: mscott → nobody
Comment 65•15 years ago
|
||
IS this bug still valid? ThunderBrowse seems to be able to handle POST as of TB3.0.
Comment 66•15 years ago
|
||
it is not because a plugin fix the problem than the bug become invalid.
it may become "won't fix", but the bug is valid
Comment 67•15 years ago
|
||
What I mean is, in TB 2.0 ThunderBrowse wasn't able to handle method="post" because Thunderbird didn't support allowing plugins to do that. Now, in TB 3.0, it does.
TB now supports method="post", but it still doesn't support browsing, which is the only sensible way of dealing with method="post" requests, and which is pretty much what bug 318104 asks for, as I'm sure you know ;)
Comment 68•15 years ago
|
||
Forms work for me in Thunderbird 3.0.1 without ThunderBrowse for both methods "get" and "post". However, the tag INPUT type="sumbit" does not work. Only the tag BUTTON type="submit" works.
I suspect that means this bug should be closed, and another one opened for the INPUT tag problem. Or maybe this bug was about the INPUT tag all along?
By the way, I can think of perfectly sensible uses for forms that do not require browsing. For example, the PHP script I used for testing replied by e-mail.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•