From: Tomas K. <to...@us...> - 2003-11-23 15:46:41
|
Hi, what variables have to be preserved when creating URLs in read_body.php Show Unsafe images link uses mailbox, passed_id, startMessage, view_unsafe_images, ent_id, sort, show_more, passed_ent_id. formatRecipientString function in read_body uses PHP_SELF when it creates URLs, but this causes problems with delete_move_next. Do I really have to check all the variables used by show_unsafe_images, if I want to fix formatRecipientString? function can't use PHP_SELF, because delete_move_next uses POST requests and variables are not present in URL. Also plugin can use GET request with variable that deletes other message. If you want to see error, go to message that is newer that GPG plugin announcement, move that message or delete it with delete_move_next button or link and try expanding recipient list in announcement. -- Tomas |
From: <pdo...@an...> - 2003-11-24 23:04:43
|
> what variables have to be preserved when creating URLs in read_body.php > > Show Unsafe images link uses mailbox, passed_id, startMessage, > view_unsafe_images, ent_id, sort, show_more, passed_ent_id. Seems like a good start. I can't remember any more off the top of my head. But.... > formatRecipientString function in read_body uses PHP_SELF when it creat= es > URLs, but this causes problems with delete_move_next. > > Do I really have to check all the variables used by show_unsafe_images,= if > I want to fix formatRecipientString? function can't use PHP_SELF, becau= se > delete_move_next uses POST requests and variables are not present in UR= L. > Also plugin can use GET request with variable that deletes other messag= e. I'd say fix delete_move_next instead. That plugin shouldn't be pulling directly from $_GET or $_POST itself. It should definitely be using the SM functions for that (sqGetGlobalVar). If thus fixed, it won't need any of those if statements that check for the variables' existance, and it'll work for older PHP versions w/out autoglobals, can pull from GET or POST without caring which one (SQ_FORM), and will be generally more solid code= . I can volunteer to do the fix if you don't want to. Cheers, Paul |
From: Jimmy C. <ji...@ad...> - 2003-11-25 04:22:12
|
pdo...@an... said: >> what variables have to be preserved when creating URLs in read_body.php >> >> Show Unsafe images link uses mailbox, passed_id, startMessage, >> view_unsafe_images, ent_id, sort, show_more, passed_ent_id. > > Seems like a good start. I can't remember any more off the top of my > head. But.... > >> formatRecipientString function in read_body uses PHP_SELF when it >> creates >> URLs, but this causes problems with delete_move_next. >> >> Do I really have to check all the variables used by show_unsafe_images, >> if >> I want to fix formatRecipientString? function can't use PHP_SELF, >> because >> delete_move_next uses POST requests and variables are not present in >> URL. >> Also plugin can use GET request with variable that deletes other >> message. > > I'd say fix delete_move_next instead. That plugin shouldn't be pulling > directly from $_GET or $_POST itself. It should definitely be using the > SM functions for that (sqGetGlobalVar). If thus fixed, it won't need any > of those if statements that check for the variables' existance, and it'll > work for older PHP versions w/out autoglobals, can pull from GET or POST > without caring which one (SQ_FORM), and will be generally more solid code. > > I can volunteer to do the fix if you don't want to. > > Cheers, > > Paul While we are at it, should we start converting the core plugins to actually be SM Plugin compliant? I can start on making those changes for devel if need be.... Jimmy |
From: <pdo...@an...> - 2003-11-26 00:04:48
|
> While we are at it, should we start converting the core plugins to > actually be SM Plugin compliant? I can start on making those changes > for devel if need be.... Absolutely. You should keep me/us informed as to which ones you're picking up, so we don't duplicate efforts. Cheers, Paul |
From: Tomas K. <to...@us...> - 2003-11-25 07:22:31
|
> > formatRecipientString function in read_body uses PHP_SELF when it > creates > > URLs, but this causes problems with delete_move_next. > > > > Do I really have to check all the variables used by > show_unsafe_images, if > > I want to fix formatRecipientString? function can't use PHP_SELF, > because > > delete_move_next uses POST requests and variables are not present in > URL. > > Also plugin can use GET request with variable that deletes other > message. > > I'd say fix delete_move_next instead. That plugin shouldn't be pulling > directly from $_GET or $_POST itself. It should definitely be using the > SM functions for that (sqGetGlobalVar). If thus fixed, it won't need any > of those if statements that check for the variables' existance, and it'll > work for older PHP versions w/out autoglobals, can pull from GET or POST > without caring which one (SQ_FORM), and will be generally more solid code. > > I can volunteer to do the fix if you don't want to. delete_move_next uses GET when it deletes message and goes to next/previous. URL includes bunch of variables. But when plugin has to move message to other folder, it has to use POST. URL contains only read_body.php. That's the way forms work. I don't think that you will be able to change that part. PHP_SELF is used by formatRecipientString and I'll fix it in two days. delete_move_next needs only fixes for situation, when server side sorting is disabled. Bugs No. 748498, 794879 |
From: <pdo...@an...> - 2003-11-25 08:37:18
|
>> > formatRecipientString function in read_body uses PHP_SELF when it >> creates >> > URLs, but this causes problems with delete_move_next. >> > >> > Do I really have to check all the variables used by >> show_unsafe_images, if >> > I want to fix formatRecipientString? function can't use PHP_SELF, >> because >> > delete_move_next uses POST requests and variables are not present in >> URL. >> > Also plugin can use GET request with variable that deletes other >> message. >> >> I'd say fix delete_move_next instead. That plugin shouldn't be pullin= g >> directly from $_GET or $_POST itself. It should definitely be using t= he >> SM functions for that (sqGetGlobalVar). If thus fixed, it won't need >> any >> of those if statements that check for the variables' existance, and >> it'll >> work for older PHP versions w/out autoglobals, can pull from GET or PO= ST >> without caring which one (SQ_FORM), and will be generally more solid >> code. >> >> I can volunteer to do the fix if you don't want to. > > delete_move_next uses GET when it deletes message and goes to > next/previous. URL includes bunch of variables. > > But when plugin has to move message to other folder, it has to use POST= . > URL contains only read_body.php. That's the way forms work. > > I don't think that you will be able to change that part. Hrm, yes, not easily, unless all that junk has been globalized, or we add it to the parameters of the do_hook function call (which, in many places, is actually a very good, very useful idea). > PHP_SELF is used by formatRecipientString and I'll fix it in two days. such that you add all those variables as GET variables on the URL?=20 probably the fastest fix, you're right, although delete_move_next should still use sqGetGlobalVar anyway... maybe I'll hit that one if I decide to parse through some of the other delete-move-next bugs, or are you focusin= g on that? (there've been several very good patches submitted over the last several months that could be used to fix some problems it has (particularly with threaded message lists) > delete_move_next needs only fixes for situation, when server side sorti= ng > is disabled. Bugs No. 748498, 794879 Cheers, - Paul |
From: Tomas K. <to...@us...> - 2003-11-25 09:22:50
|
> > PHP_SELF is used by formatRecipientString and I'll fix it in two > days. > > such that you add all those variables as GET variables on the URL? 1. starting url = read_body.php 2. add variables that have to be included (startMessage, mailbox, passed_id) 3. if other variables are set, add them too. I want to check the purpose of $sort and $show_more before fixing and I don't have any plans about delete_move_next. |
From: <pdo...@an...> - 2003-11-25 10:13:07
|
>> > PHP_SELF is used by formatRecipientString and I'll fix it in two >> days. >> >> such that you add all those variables as GET variables on the URL? > > 1. starting url =3D read_body.php > 2. add variables that have to be included (startMessage, mailbox, > passed_id) > 3. if other variables are set, add them too. > > I want to check the purpose of $sort and $show_more before fixing and I I believe $sort indicates how the current message list is sorted... from functions/mailbox_display.php * 0 =3D Date (up) * 1 =3D Date (dn) * 2 =3D Name (up) * 3 =3D Name (dn) * 4 =3D Subject (up) * 5 =3D Subject (dn) It's also saved as a user pref (per folder), so $sort should indicate the sort for the current folder. $show_more is the way that read_body.php indicates that all the recipient addresses should be displayed... watch out for show_more_cc and _bcc that do the same for the relevant fields. > don't have any plans about delete_move_next. OK, will put it on my list... - paul |
From: Jonathan A. <jo...@sq...> - 2003-11-25 15:24:51
|
Hello Tomas, On Sunday, November 23, 2003, Tomas Kuliavas wrote... > what variables have to be preserved when creating URLs in read_body.php > Show Unsafe images link uses mailbox, passed_id, startMessage, > view_unsafe_images, ent_id, sort, show_more, passed_ent_id. > formatRecipientString function in read_body uses PHP_SELF when it creates > URLs, but this causes problems with delete_move_next. I completely missed something... shouldn't read email at 3am... what problems does it cause? As Paul said, it should be using sqGetGlobalVar, but I've not seen any issues... mind detailing them? > Do I really have to check all the variables used by > show_unsafe_images, if I want to fix formatRecipientString? function > can't use PHP_SELF, because delete_move_next uses POST requests and > variables are not present in URL. Also plugin can use GET request > with variable that deletes other message. Hence the SQ_FORM option, as forms can be done via POST and GET. That should resolve this I'd have thought. But then again, I don't know exactly what's wrong. > If you want to see error, go to message that is newer that GPG plugin > announcement, move that message or delete it with delete_move_next button > or link and try expanding recipient list in announcement. Hrm... I'm not entirely sure without looking, shall take a peek. -- Jonathan Angliss (jo...@sq...) |
From: Tomas K. <to...@us...> - 2003-11-25 17:56:33
|
> I completely missed something... shouldn't read email at 3am... what > problems does it cause? As Paul said, it should be using > sqGetGlobalVar, but I've not seen any issues... mind detailing them? When I move one message to different folder and go to another message, PHP_SELF="http://domain.tld/src/read_body.php" URL that expands long Recipient list looks like "http://domain.tld/src/read_body.php?show_more=1" No mailbox, no message id ERROR: ERROR : Could not complete request. Query: SELECT "" Reason: Invalid mailbox URL should look like http://domain.tld/src/read_body.php?mailbox=INBOX&passed_id=13870&startMessage=1&show_more=1 I know how to put these variable into url, if you know how to make link work with "http://domain.tld/src/read_body.php?show_more=1", then i don't have to fix it. It is possible that extra variables needed to cover other plugins or features. get email with external images, turn on external image display, expand long recipient list. If I don't keep view_unsafe_images variable - unsafe_images will be blocked again. $ent_id and $passed_ent_id are used to track which part of message I am viewing. $sort - some sorting and I suspect that it does not have to be included in GET request. |
From: <pdo...@an...> - 2003-11-25 20:23:46
|
> URL should look like > http://domain.tld/src/read_body.php?mailbox=3DINBOX&passed_id=3D13870&s= tartMessage=3D1&show_more=3D1 > > I know how to put these variable into url, if you know how to make link > work with "http://domain.tld/src/read_body.php?show_more=3D1", then i d= on't > have to fix it. as you said, I don't think there is any way to fix it beside passing all those other variables > $ent_id and $passed_ent_id are used to track which part of message I am > viewing. $sort - some sorting and I suspect that it does not have to be > included in GET request. I think sort might be important for returning to message list interface(?= ) or other... it's probably safer to pass it along just in case. |
From: Jonathan A. <jo...@sq...> - 2003-11-25 20:50:50
|
Hello Pdontthink, On Tuesday, November 25, 2003, pdo...@an... wrote... >> URL should look like >> http://domain.tld/src/read_body.php?mailbox=INBOX&passed_id=13870&startMessage=1&show_more=1 >> >> I know how to put these variable into url, if you know how to make >> link work with "http://domain.tld/src/read_body.php?show_more=1", >> then i don't have to fix it. > as you said, I don't think there is any way to fix it beside passing > all those other variables Maybe I'm missing something... this whole thread seems a little hazy to me for some reason... but passed_id is already sent on delete/move of a message... did I really have that bad of a week that I don't see what this is about? >> $ent_id and $passed_ent_id are used to track which part of message I am >> viewing. $sort - some sorting and I suspect that it does not have to be >> included in GET request. > I think sort might be important for returning to message list interface(?) > or other... it's probably safer to pass it along just in case. It shouldn't be needed. On the loading of the page, the preferences are loaded, and as such, the sort options for that folder /should/ be loaded. If you pass $sort, it saves the preference for that folder. If you're inside a message, passing this variable around is fairly useless. -- Jonathan Angliss (jo...@sq...) |
From: <pdo...@an...> - 2003-11-26 00:03:06
|
>>> URL should look like >>> http://domain.tld/src/read_body.php?mailbox=3DINBOX&passed_id=3D13870= &startMessage=3D1&show_more=3D1 >>> >>> I know how to put these variable into url, if you know how to make >>> link work with "http://domain.tld/src/read_body.php?show_more=3D1", >>> then i don't have to fix it. > >> as you said, I don't think there is any way to fix it beside passing >> all those other variables > > Maybe I'm missing something... this whole thread seems a little hazy > to me for some reason... but passed_id is already sent on delete/move > of a message... did I really have that bad of a week that I don't see > what this is about? The URL that is used for all the links in read_body.php (the "more" link, for example) uses $PHP_SELF, which is expected to have all the needed variables, since most calls to read_body pass their information in via GET. In the case of the *move* functionality of the delete-move-next plugin, there is a <form>, where those variables are passed using POST.=20 So after moving a message, the $PHP_SELF variable is stripped down and doesn't have enough information in it. Tomas, one other option here would be to change the method attribute of the form tag for the delete-move-next plugin to be GET instead of POST... - Paul |
From: Jonathan A. <jo...@sq...> - 2003-11-26 05:05:51
|
On Tue, 2003-11-25 at 17:57, pdo...@an... wrote: > > Maybe I'm missing something... this whole thread seems a little hazy > > to me for some reason... but passed_id is already sent on delete/move > > of a message... did I really have that bad of a week that I don't see > > what this is about? > > The URL that is used for all the links in read_body.php (the "more" link, > for example) uses $PHP_SELF, which is expected to have all the needed > variables, since most calls to read_body pass their information in via > GET. In the case of the *move* functionality of the delete-move-next > plugin, there is a <form>, where those variables are passed using POST. > So after moving a message, the $PHP_SELF variable is stripped down and > doesn't have enough information in it. Okay, it really was a long week... hehe... now I see... god... need to do less work at 2-3am :) I'd say there is nothing wrong with DMN in this case, and it's the fault of the function to expand the headers. Making an assumption that something is going to be complete is wrong... you should check it. $PHP_SELF should only refer to the file. > Tomas, one other option here would be to change the method attribute of > the form tag for the delete-move-next plugin to be GET instead of POST... Why? I guess I'm having my blonde moment :) It's been too long of a week. -- Jonathan Angliss (jo...@sq...) |
From: <pdo...@an...> - 2003-11-26 06:47:48
|
>> The URL that is used for all the links in read_body.php (the "more" >> link, >> for example) uses $PHP_SELF, which is expected to have all the needed >> variables, since most calls to read_body pass their information in via >> GET. In the case of the *move* functionality of the delete-move-next >> plugin, there is a <form>, where those variables are passed using POST= . >> So after moving a message, the $PHP_SELF variable is stripped down and >> doesn't have enough information in it. > > Okay, it really was a long week... hehe... now I see... god... need to > do less work at 2-3am :) I'd say there is nothing wrong with DMN in > this case, and it's the fault of the function to expand the headers. > Making an assumption that something is going to be complete is wrong... > you should check it. $PHP_SELF should only refer to the file. except that would require more of a rebuild of read_body... >> Tomas, one other option here would be to change the method attribute o= f >> the form tag for the delete-move-next plugin to be GET instead of >> POST... > > Why? Because then the URL should have all the variables in it that read_body expects to be in PHP_SELF.... except, as Tomas pointed out, that would also contain the ID of the message to be deleted/moved... and we certainl= y don't want that a 2nd time. > I guess I'm having my blonde moment :) It's been too long of a > week. I've had more than you. :) |
From: Jonathan A. <jo...@sq...> - 2003-11-26 08:41:40
|
On Wed, 2003-11-26 at 00:41, pdo...@an... wrote: > > Okay, it really was a long week... hehe... now I see... god... need to > > do less work at 2-3am :) I'd say there is nothing wrong with DMN in > > this case, and it's the fault of the function to expand the headers. > > Making an assumption that something is going to be complete is wrong... > > you should check it. $PHP_SELF should only refer to the file. > > except that would require more of a rebuild of read_body... So more parts in read_body expect $PHP_SELF to contain all the variables straight away? I think we might need to address this... anybody think the same? I think being expectant on values will cause issues, like we're having now. > >> Tomas, one other option here would be to change the method attribute of > >> the form tag for the delete-move-next plugin to be GET instead of > >> POST... > > > > Why? > > Because then the URL should have all the variables in it that read_body > expects to be in PHP_SELF.... except, as Tomas pointed out, that would > also contain the ID of the message to be deleted/moved... and we certainly > don't want that a 2nd time. You wouldn't have the message id of the message to be deleted/moved twice. That ID gets put in a different var depending on what you're doing. The DMN plugin then sets passed_id to the next/prev msgid depending on the link (prev/next). OOooh... hang on... I think I know what you mean now. The delete function is (should be) fine... it's the move part of the DMN plugin that is causing hell. Because it's using _POST, the code that builds the URL for the rest of the page never works right because of the vars aren't in the URL. This then generates incomplete URLs. And you were saying that if you were to move the move part to _GET instead, you'd get passed_id duplicated... one containing the selected message, the other containing the next message. Of course, if you issues a move, the selected message would no longer be there, and would likely cause issues. NOW I see... hehe... I've been trying to work out what delete had to do with anything, but it really doesn't... it's just move. The changes shouldn't be that hard then... just for the move form (because there is only one part), build most of the URL as part of the action... ie: <form name="dmn_move" method="post" action="src/read_body.php?passed_id=" . $passed_id_new . "&mailbox=INBOX" . "&startMessage=5"> <input type="hidden" name="move_id" value=4> [..] </form> That then sends a _GET and a _POST (tried it with a range of browsers), at least in terms of PHP fetching the data. > > I guess I'm having my blonde moment :) It's been too long of a > > week. > > I've had more than you. :) More blonde moments? Or a longer week? I think the fact that I've been reading this thread for several days, repeatedly to try and work things out, and only just got it (at 2:40am)... I think I just tallied another moment :) -- Jonathan Angliss (jo...@sq...) |
From: <pdo...@an...> - 2003-11-26 20:48:26
|
> NOW I see... hehe... I've been trying to work out what delete had to do > with anything, but it really doesn't... it's just move. > > The changes shouldn't be that hard then... just for the move form > (because there is only one part), build most of the URL as part of the > action... ie: > > <form name=3D"dmn_move" method=3D"post" > action=3D"src/read_body.php?passed_id=3D" . $passed_id_new . > "&mailbox=3DINBOX" . > "&startMessage=3D5"> > > <input type=3D"hidden" name=3D"move_id" value=3D4> > [..] > </form> > > That then sends a _GET and a _POST (tried it with a range of browsers), > at least in terms of PHP fetching the data. Good call! Now if we could all expend as much energy on some more important issues... :) - Paul |