Apr 3, 2007, 5:21 AM
Veteran / Moderator (6956 posts)
Apr 3, 2007, 5:21 AM
Post #2 of 2
Views: 2436
What exactly are you trying to do?
How are the plugins set up to be used in the admin?
If anything is going as a "request" through the browser, and the user is not logged in to the admin, it won't work. The server will block the request.
You need to call the plugins from inside the templates, or from scripts the user has access to. The plugins themselves can be called from anywhere (Glinks has access to any files of it's own). The request,though, has to come from inside GLinks, or from a script in a user (moderator) accessible area.
I've been doing a *lot* of work having plugins (and whole scripts) being called from inside the templates. Unlike PHP, this doesn't embed any "code" only the request to run a block of code, or to get some variables. After a lot of rethinking of things, rather than having scripts that run, and spit out templates, it's much more logical to have templates (a display/action/request) run the scripts/modules/functions they need to give you what you wanted. Security is within the modules, making sure users are logged in, have permissions, or are admins or moderators.
In fact, the templates have commands that end parsing, and can send the user elsewhere (look at the category.html). By doing that, you can check user status, and authorization to run that template before it loads, using an external routine, and direct the user to log on, or to force a display-only page, rather than an edit/update page. You can get better security in some ways, by aborting output when tags/status don't match -- even after the intial access checks.
Most of my new/revised plugins are template-driven, not script driven. That puts almost all the design power in the hands of the template editors and basic HTML/tags rather than PERL code or programmers. You can change how the program operates and responds by changing the templates and calling stock functions (or your own functions) from within them. Because each function/codeblock has it's own security, and should function like a script, if it's improperly called, or called without sufficient user security it generates an error, or default behavior. But, by not calling a script.cgi first, and breaking up the logic of each code block, all things are possible. :)
This fits well with the loop_ variables, and arrays being returned by sections of GLinks code, and the display loops being added into the various templates. The data is returned by a fuction call (either from the script or a call within the template) and the template, which is much easier to edit, decides how it's displayed.
Scripts can provide "flow" control, or form processing, and enforce general rules, while the templates allow you to affect/alter the actual output.
Like I said, I had a lot of off-line time to re-think a whole lot of things, from the ground up, and from a display/output stand point rather than a pre-programed script output. You can think of it more as "event" driven (from template requests, rather than user mouse input), rather than top-down design. That's not an exact analogy, but it might help.
I have not tackled the browser.cgi, or any of the JS code, I don't want to learn JS, or AJAX :(, but my first thoughts would be that to do what you want, you want to either create a set of templates, that at the very top check to make sure the user is has access (is an editor/moderator), then will load the right templates/functions for that request. You could embed that in the templates loaded by browser.cgi, again, using an IF to decide if a user sees that specific link, before they can even attempt to run it (two levels of security, what can't be seen, is often ignored).
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
