Re: PHP versus CGI
On 2/20/04 12:00 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Thanks, that's interesting :-) I placed the files in the specified folder, according to read-me... But I have still a number of questions: - where to place the engine? - is the MC engine (which went with MC 2.5) good? - may I use this server locally? and how? I could never FIND the rev engine for darwin mc - thanks for posting the link, Jacqueline! The rev engine appears to work the exact same way the darwin mc engine works. But the engine is NOT identical... It's slightly smaller than the darwin mc engine, and looks like it has a later created date. I'd love to know what the difference is - probably not much. As far as where to place it, I opted for the traditional location for stuff... I put it in /usr/bin. On OS X, if you want to get to that folder in the Finder you have to use Go To Folder from the Go menu and type /usr/bin. From that point on, any scripts you write must begin with the header, #!/usr/bin/rev And if you plan on writing scripts using a text editor, I recommend BBEdit Lite, which can save with UNIX line breaks, which is what you need. Or you could write your own text editor in MetaCard or Revolution that saves using UNIX line breaks, I guess. :) Once you drag the rev executable to the /usr/bin folder, you need to give it the ability to run. In the command line, type sudo chmod 555 /usr/bin/rev As far as running scripts locally, you can do that. You can write any script to do anything you want, and then schedule that script to run any time you want, for example, or put it in the CGI-Executables folder and do cgi stuff with it and whatnot. There's a free program called Cronnix that is a GUI tool for setting cron jobs. That's how I schedule my server scripts to run. The other cool thing about Cronnix is that you can click on any script you've got scheduled to run and run it immediately. Actually, our district has a filemaker pro server available with all of our students in it, and I use a combination of filemaker pro and darwin mc to automatically add new students to ldap. Darwin mc scripting (and thus, rev scripting) is c-o-o-l for programming servers! -- :) Richard MacLemale Network Administrator J. W. Mitchell High School ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: PHP versus CGI
Um, OUCH! There is ALREADY a file named rev in /usr/bin. So much for storing the rev runtime executable in /usr/bin under OS X. Fortunately, it appears you can just rename the rev file to something different, like runrev. It still works... There is no default file in /usr/bin named mc, however... -- :) Richard MacLemale Network Administrator J. W. Mitchell High School ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: PHP versus CGI
J. Landman Gay [EMAIL PROTECTED] wrote: http://www.hyperactivesw.com/downloads/IntroRevCGIs.zip Thanks, that's interesting :-) I placed the files in the specified folder, according to read-me... But I have still a number of questions: - where to place the engine? - is the MC engine (which went with MC 2.5) good? - may I use this server locally? and how? -- Vous parlez français ? faites un tour sur le groupe francophone ! [EMAIL PROTECTED] Jetez un oeil sur RevoBlog http://revoblog.free.fr ! ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: PHP versus CGI
Can you elaborate? What kind of details? And did you mean intrinsic or explicit? ;-) * PHP is safer than CGI unless you add a lot to CGI ; Actually, MC CGIs are probably the most secure as they will only run scripts that are in the cgi-bin folder with the engine. You can't send it a script to run from the outside, so it will only do what it has been preprogrammed to do. Or at least that's my understanding... A nice thing would be that someone with good CGI knowledge and competences could right a short tutorial (with clear DOs and DON'Ts) about using Rev CGI and how to configure a server (privileges settings, etc) in that context. This could be put online on the Developers web page at RR. I'm sure lots of users would benefit from that. So far only bits pieces of info can be found on the MC or Rev lists archives. If I had the knowledge, I'd gladly write such a tutorial... Thanks, JB ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: PHP versus CGI
On 2/18/04 2:59 AM, jbv wrote: A nice thing would be that someone with good CGI knowledge and competences could right a short tutorial (with clear DOs and DON'Ts) about using Rev CGI and how to configure a server (privileges settings, etc) in that context. That's been my plan ever since MacWorld, but I haven't had time to get to it yet. However, my presentation notes are available for download here: http://www.hyperactivesw.com/downloads/IntroRevCGIs.zip I think what is in there should answer most of the main questions. I just need to find time to edit the material to make it into a tutorial. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: PHP versus CGI
FWIW, PHP sometimes _is_ run as a CGI script. It's not the norm, but PHP is just the language. The advantage that PHP, Perl and others have it that they have commonly installed web-server modules installed, which is basically a built-in CGI. - Brian * PHP is widely-used and popular ; * PHP deals with many of the intricit details ; * PHP is safer than CGI unless you add a lot to CGI ; * PHP is supported by most service providers/hosts ; * PHP is part of the very dominant dev platform: LAMP ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: PHP versus CGI
* PHP deals with many of the intricit details ; Can you elaborate? What kind of details? And did you mean intrinsic or explicit? ;-) * PHP is safer than CGI unless you add a lot to CGI ; Actually, MC CGIs are probably the most secure as they will only run scripts that are in the cgi-bin folder with the engine. You can't send it a script to run from the outside, so it will only do what it has been preprogrammed to do. Or at least that's my understanding... Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: PHP versus CGI
* PHP deals with many of the intricit details ; Did you mean intrinsic or explicit? ;-) Intricate, e.g. a large number of small details. Can you elaborate? What kind of details? With PHP, all the web-form's elements are automatically assigned to variables, with variable names with the same name as the corresponding form-item, such that you can use them immediately in your script without any hassle whatsoever. With CGI, you have to handle the appleEvent (on a Mac), you have to parse the request, fetch the information of the form, decode the special chars, etc. Then, and only then, can you USE the info submitted in/to your script. That's a lot of extra work, particularly if you're also using any of the environment-variables of HTTP. __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: PHP versus CGI
On 2/17/04 4:53 PM, Ken Ray wrote: Actually, MC CGIs are probably the most secure as they will only run scripts that are in the cgi-bin folder with the engine. You can't send it a script to run from the outside, so it will only do what it has been preprogrammed to do. Or at least that's my understanding... Right. The only way it could become insecure is if you specifically programmed insecurity into it. For example, a CGI that takes the parameters that are passed and does them. Anyone who writes something like that, though, probably deserves whatever they get. ;) -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: PHP versus CGI
I think the mitigating factor here that's being missed somewhat (although many of the point raised are valid), is that all of these setups are mostly dependent on a properly-configured webserver. If you configure things in a secure fashion, someone can write the most malicious of CGIs and it won't be able to do anything. It'll run under a user that doesn't have write access to anywhere secure, and even if it purposefully crashes itself, it'll just go away and end up making the webserver return an error page. MetaCard can't write to disk if the user that launched the application can't. Bad configurations make modules and CGIs both a potential hazard, good configurations make it nearly impossible to do any harm with either. Well, unless you are on a Microsoft platform... - Brian ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: PHP versus CGI
On Feb 17, 2004, at 5:07 PM, Brian Yennie wrote: Bad configurations make modules and CGIs both a potential hazard, good configurations make it nearly impossible to do any harm with either. Exactly my thoughts, Brian. All other things equal, security of a metacard CGI script is no different than a CGI script of Perl, Python, Bash, PHP running as CGI, etc. -- Alex Rice | Mindlube Software | http://mindlube.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: PHP versus CGI
On Feb 17, 2004, at 4:32 PM, Alain Farmer wrote:
With PHP, all the web-form's elements are
automatically assigned to variables, with variable
names with the same name as the corresponding
form-item, such that you can use them immediately in
your script without any hassle whatsoever.
Unfortunately PHP now has that feature turned off in the default
distribution. Although most ISPs probably turn it on again when
installing PHP. For maximum PHP portability you must code things like
$HTTP_GET_VARS['myvar'] and $HTTP_POST_VARS['othervar'] instead of
$myvar and $othervar
But I agree with your general point: PHP was written with web
application programming in mind, so it's easy to hit the ground
running when writing web apps with PHP.
With CGI, you have to handle the appleEvent (on a
Mac), you have to parse the request, fetch the
information of the form, decode the special chars,
etc. Then, and only then, can you USE the info
submitted in/to your script. That's a lot of extra
work, particularly if you're also using any of the
environment-variables of HTTP.
Of course that depends if you are using a CGI code library or not. In
Perl it could be as easy as:
use CGI;
$query = new CGI;
$fieldValue = $query-{'fieldName'};
or something like that.
However, I've never used libCGI for MC so 'scuse me for butting in :-)
--
Alex Rice | Mindlube Software | http://mindlube.com
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard
Re: PHP versus CGI
Right. The only way it could become insecure is if you specifically programmed insecurity into it. For example, a CGI that takes the parameters that are passed and does them. Anyone who writes something like that, though, probably deserves whatever they get. ;) -- Jacqueline Landman Gay Does them? How do you do them? I know how people do lunch, but doing a parameter? Unless you mean do. As in create a miniscript, put the miniscript into lunch and then do lunch. -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: PHP versus CGI
Welcome to the fray Alex, However, I've never used libCGI for MC so 'scuse me for butting in :-) OTC, please join us. :) Alain __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
