On Wed, Jan 6, 2010 at 10:13 AM, Danny <[email protected]> wrote:
>> > According to official site it says that admins are editors, editors
>> > are members, and members are guests.
>> > So I think this would be more resonable.
>>
>> I had gone ahead and made the change, but then decided against it
>> because of this ambiguity. And also because it is so easy to add this
>> line to a config file if desired. I wonder if we shouldn't make the
>> groups that can create form configurable, so we could give admins a
>> bit more flexibility... Perhaps via a config file only, to avoid
>> opening security holes though site.config... Just an idea.
>>
> It would be a good idea to make form creating configurable.
> But so far we can still erase all @editor in auth files so that
> @editor only grants form creating permission, and the user could still
> manage the realistic auth by making other groups. So I still think
> @admin, @editor, @member, @guest hierarchy reasonable, and we could
> maybe later make some change in special feature for @admins just like
> form creation permission.
There may be instances where you would want certain users to be able
to create forms in certain situations--without granting standard
editor status. I'll look into adding an easy config option here
somewhere.
>> > BOLTcodePageGroup is a function I added to engine.php, to unify and
>> > simplify all likely things
>>
>> > function BOLTcodePageGroup($page, $type='MAIN') {
>> > ## RETURNS WHETHER A PAGE BELONGS TO CODE PAGE GROUP, WHICH MEANS THAT
>> > IT IS DISPLAYED IN CODE BOX
>> > return (BOLTpageCheck(BOLTconfig('BOLTcodePages',
>> > 'code').'*,'.BOLTconfig('BOLTtemplatePages', 'template').'*',$page)
>> > && ! BOLTpageCheck(BOLTconfig('BOLTcodePagesExclude',
>> > 'code,code.embed,template'),$page));
>> > }
>>
>> I'm not sure I want to go this route. I'll file the idea around, but I
>> think making this configurable this way could introduce security
>> issues if you have an unwise administrator. I'll file the idea away
>> and if a convincing case can be made for this, I'll be happy to add
>> it.
>
> Actually I don't like the fact that code, code.embed, and template
> pages under "code" hierarchy (I mean, displayed in a source box) but
> not so. I just like programs to be well-modalized. To better manage
> them I create this function; or I'd prefer to make those pages not
> exceptions.
> So far it is used here and another place is BOLTgetzones making "code"
> pages:
>
> old:
> if (substr($link, 0, strpos($link, ".")) == $BOLTcodePages || substr
> ($link, 0, strpos($link, ".")) == $BOLTtemplatePages ) {
> if ($link != 'code.embed') $out = "<div class=code>\n" .
> BOLTcharEncode(htmlspecialchars($out, ENT_NOQUOTES), 'lines') . "\n</
> div>";
> }
>
> new:
> if (BOLTcodePageGroup($link)) {
> $out = "<div class=code>\n" .
> BOLTcharEncode(htmlspecialchars($out,
> ENT_NOQUOTES), 'lines') . "\n</div>";
> }
I see your point. I'll think about something like this... But I am
very uncomfortable with giving admins to many options with the code
pages, because of the potential security risks.
>> I wonder if it wouldn't be helpful to simply remove all the defaults
>> from the core php code and force it them all to go into the
>> site.messages(.language) page. It should shorten the code a bit, and
>> force me to keep things current. As it is, it is simply too convenient
>> to add a message here and there and forget to add it to the
>> site.messages page. As you can see, this has happened often. :) It
>> would take some cleaning up, but in the long run it should be a
>> worthwhile investment of time. What do you think?
>
> Yes, I did and do think we should do something to collect all configs,
> messages, languages, and maybe other system params in clear lists at
> specific initial routine block instead of putting them here and there.
I've just gone through and did a major reworking of site.messages and
site.language, but still need to do more to check everything is
listed. It's a difficult job keeping it all current--when you have to
update messages some place beside the code. But it does allow many
nice customization features.
> For configs, I think we could make another function like BOLTsetConfig
> which takes a string in the identical pattern and sets the config
> array (also modify the config init part) so that users wouldn't get
> troubles by directly setting config array and get problems by adding
> "BOLT" or not using lowercase as the index name. And we can then put
> default config values alltogether in init routine instead of making
> them everywhere.
Not sure I follow you here. It's already easy to set config values via
php (the syntax isn't that hard). But one advantage to having them set
many places, is we don't need globals for everything. Maybe I'm
missing your point, but that was the goal of the BOLTconfig
function--to eliminate the need for as many globals as possible.
I think I probably just missed your suggestion. But generally, the
BoltWire config seems to be working fine.
> We could still keep BOLTconfig as current so we can still set a
> default value for some special functions seperately, and also to get
> backward compatibility for old plugins. Also, I don't think that we
> really need config name started with "BOLT". what about allowing no
> "BOLT"?
I'll look into this.
> For messages, I wonder if we need site.messages actually? It seems
> that we are messed since site.messages and site.languages could both
> affect the message output.
>
> Would it be better to define all system messages directly in an array
> variable in the core, and make site.language the only way to modify
> message output? (A problem is that if language is configured to be
> default the site.language is ignored. But we can simply add a
> "site.language.en" and put only system messages and the "translation"
> in it if we do need to change the messages in English.)
I've consider this several times before, but for an English user, the
site.messages page gives me a way to fully customize any system
messages I want to. I suppose we could use a custom English language
file for that--but it seems it would bog performance down
unnecessarily. If not, I'll be happy to make the change. It would add
even more functionality--as the ability to change many more things
about the system.
>> > It was my fault now noticing "editlines" param in Xedit and Xcreate,
>> > so just ignore it.
>> > But I don't think the transforming \n to linebreak is necessary since
>> > someone could simply type an "enter" to do equal thing. Even it's
>> > configurable, I'd prefer the default is not doing it (maybe modify
>> > action.edit, aciton.create, and action.copy?).
>>
>> Many times it is convenient to insert a line break into a form session
>> value, something like this:
>>
>> [text name]
>> [text email]
>> [box contents][box]
>> [session body "Name: {=name}\nEmail: {=email}\n\n{=contents}..."]
>>
>> That's the purpose. We may change this in the future to only make it
>> happen for session inputs, and never normal html inputs.
>
> Well.. We probably put it at the wrong place, because putting it in
> Xedit just make inputing:
>
> [session body "Name: {=name}\nEmail: {=email}\n\n{=contents}..."]
>
> actually same as the following:
> [session body "Name: {=name}
> Email: {=email}
>
> {=contents}..."]
This is not possible because it breaks the markup rule for [session...]
> Maybe we could add more markups like /= =/, /* */, <box>, <code>,
> <markup>, <html>, ` or so... I recalled that when I first touch
> BoltWire I don't know there are so many useful markups that I can use
> in the help file.
The idea is for that page to be a simple file for users, not admins. I
tried to pick the markups a general user would be most likely to use.
>> >> > 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.
>
> Oops...I must be giddy. What we really need to fix is the following
> block from 1 to 2:
>
> if ($type == 'data') {
> $page = substr($check, 0, strpos($check, ":"));
> $check = substr($check, strlen($page) + 1);
> }
No, what gets sent to BOLTauth when checking data is something like this:
BOLTauth("$page:$f", $BOLTid, 'data'))
In that case there is only a : separating the page from the field.
I've tested this a couple times. It's working. Can you give me an
example of how the test is failing?
>> >> > 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
>
> I am sure we can't because we are not considered @admin before logging
> in. I did a test in v3.3.3 and it proved.
> And what I meant to is to permit only superadmins instead of @admin
> but it's OK if you think so.
Oh, you are right. I'm open to other ideas... but shy of some kind of
authentication it seems impossible. Unless the page you get when
blocked is a login page...
Shouldn't the second line be elseif?
if ($BOLTwhiteList != '' && strpos(BOLTloadpage($BOLTwhiteList),
$BOLTvar['$ip']) === false) {print_r($IPblockedHTML);die();}
elseif ($BOLTblackList != '' && strpos(BOLTloadpage($BOLTblackList),
$BOLTvar['$ip']) !== false) {print_r($IPblockedHTML);die();}
>> >> > 10.Fixed a mistake of 3.3.2f while parsing [messages] before getting
>> >> > zones so that function messages are not showed.
>>
>> 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.
>
> Yes we can and it's tried and proven. In my process we first replace
> [messages] in BOLTdomarkup to <div class="message" /> and make a total
> replacement again after doing markup.
>
> It's a little complicated but the benefit is to reduce the hardcodes
> and to increase the freedom for users to further manage the markup
> rules. And in any point <div class="message" /> is a string that
> cannot be input in anyway so it would never mass up any markup rule
> except the one which means to create a message block. Also it won't
> make /= [messages] =/ or something like that work. Same for [results].
I am not convinced it will work in all situations, or that it is more
flexible. If a person wants some kind of different system, they simply
don't use [messages] on the page and add whatever markup rule they
want. If a person wanted to go further, they could always take
advantage of the makepage hook to eliminate this feature. But doing it
in domarkup is impossible if you have a message coming from say the
bottom zone, and the [messages] markup is in the main page. It has to
be rendered after all the zones have been processed.
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.
