| Re: approaches to PHP-based application interface? [message #176733 is a reply to message #176722] |
Fri, 20 January 2012 12:21   |
crankypuss
Messages: 147
Registered: March 2011
Karma:
|
Senior Member |
|
|
On 01/20/2012 02:43 AM, Erwin Moller wrote:
> On 1/20/2012 9:53 AM, crankypuss wrote:
>> On 01/19/2012 08:00 AM, The Natural Philosopher wrote:
>>> crankypuss wrote:
>>>> I'm not even sure how to ask the question. Maybe it's several
>>>> questions.
>>>>
>>>> Supposing one wants to run a local apache server that supports a
>>>> PHP-based system interface, things like file editing, file management,
>>>> archive support, and various other applications. For some things like
>>>> file management it may need root privileges. It also needs to be
>>>> "safe" so that the applicable parts of it can run on a public server.
>>>> Are there approaches to this that have been successfully used in the
>>>> past?
>>>>
>>>> One major advantage of sticking with PHP is that my fairly large
>>>> codebase won't need to be rewritten. The html/browser paradigm is
>>>> perfectly adequate to all the things that I can foresee doing. On
>>>> Windows there is this thing, http://www.zzee.com/php-gui/
>>>> What it does is let you plug your PHP browser-based application into a
>>>> stripped-down browser so it runs as a Windows application without any
>>>> apache involvement. But I wish to do this on Linux.
>>>>
>>>> Failing both those approaches, can anyone recommend a good GUI package
>>>> that supports PHP applications, preferrably something gtk-based?
>>>>
>>>> Sorry this is such a scattered question. Basically I'm working on
>>>> building a system-independent PHP-based system front-end, parts of
>>>> which can be made available on a public web server.
>>>
>>> well look at webmin first, before you decide to 'go php' for everything.
>>>
>>> There are good reasons NOT to be TOTALLY php as well.
>>>
>>> Vis if the whole php regime has 'root access' ten you are in deep
>>> trouble if someone hacks the php layer.
>>>
>>> Better to write specific tools in - say C - that are expressly 'su root'
>>> type programs designed to edit just one part of the installation.
>>>
>>> So you might write a C program that can READ any file in /var/log with
>>> any permissions, but not WRITE one. So as to get to your log files for
>>> example. But not alter them.
>>>
>>> That the way we access mysql - we cant from php access the raw data
>>> files, but mysqld is a daemon that can, and we talk to that...
>>>
>>>
>>> Miking this easier for yourself always makes it easier for an
>>> incompetent or malicious person to screw things up as well.
>>
>> "Webmin is a web-based interface for system administration for Unix."
>>
>> I'm not really much interested in "system administration", but thanks
>> for the thought.
>>
>>
>> What I'm really looking at is more about replacing user interfaces like
>> Ubuntu's Unity with something "browser-based" but which does not require
>> an apache server.
>>
>> And I'm not looking to grant everyuser the privileges of root for that
>> matter, just not wanting to restrict those who have access to root
>> privileges via sudo for example.
>>
>> I'm starting to wonder if what Firefox calls a content-plugin could be
>> used to recognize php and invoke the interpreter to run a file in the
>> user's available realm in the "non-cli" mode that apache runs php in.
>>
>> Apache can't very well determine what user on localhost has sent it a
>> request, as far as I've been able to find. Maybe there's some way to
>> determine that based on the remote-user's port number but I'd really
>> prefer not even to have apache involved if I can avoid it.
>>
>> I found php-gtk but it doesn't seem very much alive.
>>
>
> Just a "me too!".
Thanks, it's good to know I'm not the only nut in this asylum! <g>
> I have been looking into this also, without success.
> I tried php-gtk and gave up on it. After a few days fiddling around with
> it I only became frustrated.
Sounds as though my instincts on that one were lucky for a change...
basically I couldn't find a debian-type repository, didn't want to build
from source, and didn't like the idea of an object-oriented interface,
so I decided to keep looking and thinking.
>> Still scratching my head on this one. It isn't even clear to me why most
>> every browser supports client-side javascript but client-side php is an
>> unmentionable. In a nutshell it may be that what I'm looking for is a
>> browser that supports client-side php.
>
> That ZZEE sounds promising indeed. But W$ only.
> http://www.zzee.com/php-gui/
> Drawback is possibly that it is IE-based. It uses the IE installed on
> the system of the one that executes the ZZEE-program.
If so, that's a change from the version I tried, it had a built-in browser.
> That means you have to be careful with your HTML (in case of IE6 or
> something like that) if you distribute the program.
I tried ZZEE a year or three back, and thought it was really quite good.
It used a built-in browser, but at the time it didn't provide the
basic "find" command, which I considered a significant issue for my
purposes. Since the browser is/was fixed/builtin, Microschmoo can do
whatever they want without affecting apps. But it's Windows-only, and
they want money for it... might be a good open-source project to build
such a thing, I dunno enough about gecko et-al to know how much work it
would be. But only fairly trivial mods were needed to make the
applicable parts of my existing web code work under it, all of them
related to system-identification and easily done.
I went to wampserver instead and was very satisfied with it for
developing on Windows, but now that I'm on Linux it's easy enough just
to install apache2 and php5.
> I gave up on it and decided to go with Java. QT is another option, but I
> knew how to program in Java already, so that was the obvious choice.
>
> If you find anything, please let us know in here. :-)
>
> Good luck.
> Regards,
> Erwin Moller
Thanks, Erwin.
I was forced at near-gunpoint about a decade ago to write a Java
application... ahem, not my cuppa, no further comment. <g>
After some little thought I've concluded that a content-plugin that
allowed client-side PHP would be a real can of worms since PHP is not
designed to be sandboxed like javascript.
The approach I'm currently considering is basically to have the web
server run as root, if a request is coming from offsystem su to a less
privileged userid, if it's an onsystem request determine who the userid
is that owns the incoming port and su to his userid. Sort of like
mod_userdir only for privileges. But I'm skittish about it and will
have to do lots of thinking before I actually go there.
Read your subthread about GUI and not-GUI and music and stuff... one of
the big reasons I'm doing this is to build the kind of interface that I
want to use, which does *not* mean clicking the mouse every time I want
to scratch something. There's a place for GUI certainly, and a place
for key-by-key interaction, but I can pick up enough key-by-key using
some javascript on the front-end. Whatever, eh? <g>
BTW, does anyone know how to code a Linux script that will use PHP if
it's installed but fall back to bash if not? There is probably some
funky combination of comment strings will do that but I don't yet know
what it is.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]