On Tue, Jan 5, 2010 at 11:53 AM, Danny <[email protected]> wrote:
>> > 2) When saving data via a form, the system does not properly check
>> > auth.data
>>
>> In my test this seems to work either way. If I am mistaken, send me an
>> offlist email with more specifics.
>
> No it doesn't. It doesn't check write auth at all so anyone can write
> data to anywhere. In BOLTauth:
>
> old:
> if (strpos($line, ": ") === false) continue;
> $f = substr($line, 0, strpos($line, ": "));
> $f = str_replace('{id}', $BOLTid, $f);
> $v = trim(substr($line, strpos($line, ": ") + 1));
>
> new:
> $pos = strpos($line, ": ");
> if ($pos === false) continue;
> $f = substr($line, 0, $pos);
> $v = trim(substr($line, $pos + 2));
>
> The keypoint is "1" to "2", others are just some optomization.
I think it does work. The trim clears out the extra space at the
beginning just fine. But it is changed to 2 now, as that is more
precise.
>> > However I still think it's not good to write it this way, which may
>> > lock the superadmin himself.
>>
>> Good point. Seems the easiest way is to wrap the whole little routine in
>> if (BOLTingroup('admin') === false) { }
>
> No it wouldn't work. Because login page will be locked.
To login, you just use &action=login
>> > 2. The return value of Xvalidate seems unreasonable. I thought it
>> > should be just like Xif.
>>
>> What do you mean?
>
> Xvalidate returns the string after " ? " , while Xif returns 'true' or
> 'false'.
> I think the latter would be more resonable.
Oh, I see what you mean. Excellent suggestion! I think what we want is
to replace the last line of BOLTXvalidate with these two:
if ($c == 1) return 'true';
return 'false';
>> > 5. Fixed a missense in system page action.search so that it shows the
>> > last query input after submitting the form. I also simplified the
>> > param name from myquery to q.
>>
>> Actually I am planning to fix this a different way. The idea is to
>> keep the query cached for speed. But keep it connected to a specific
>> user and page.
>
> I mean, in action.search, added a line of passdata: [session passdata
> myquery]
> I'd favor changing "myquery" to "q" as mentioned before but it's OK
> not to do. Just up to you.
Ok, I got it. Thanks again...
>> > 9. Changed code.script back to site.script and the related scripts.
>> > Also fixed several missenses so that [(script)] works properly.
>>
>> What is currently wrong with the script function?
>
> It doesn't work, modify > to > :
> old: preg_match_all('/(<|<):([_a-z0-9.]+):> ?(.*?)(?=\n<:|
> \n<:|$)/s', $script, $commands); // if enable full markup, change \n
> to <br />
> new: preg_match_all('/(<):([_a-z0-9.]+):> ?(.*?)(?=\n<:|$)/
> s', $script, $commands); // if enable full markup, change \n to <br /
>
> I deleted the support of < to simplify and improve performance since
> they should have already be escaped.
Ok thanks again for another fix.
>> > 10.Fixed a mistake of 3.3.2f while parsing [messages] before getting
>> > zones so that function messages are not showed.
>>
>> I think function messages are supposed to be shown...
>
> Forgive my poor English. I meant that it doesn't shown and I fixed so
> it shows.
It seems function messages work in the main BoltWire core. I am not in
any way planning to move messages from BOLTmakepage to BOLTdomarkup.
I've tried both ways more than once--but to get a full system wide
return of all messages from all zones, it cannot be done in
BOLTdomarkup. So I really think it needs to stay where it is.
Cheers,
Dan
--
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/boltwire?hl=en.
