Gossamer Forum
Home : Gossamer Threads Inc. : Discussion :

blog application

Quote Reply
blog application
Does GT Dev willing to to build a Blog application to run along with G Community in the near future?

Such application is now becoming very requested and important for community sites to offer to users.

Thanks
Antoine
Quote Reply
Re: [antoined] blog application In reply to
A blog plugin for LSQL is under development

http://www.gossamer-threads.com/...;;page=unread#unread

CCUnet
my Christian web
Quote Reply
Re: [ccunet] blog application In reply to
I had tied http://geeklog.net and found it quite good with things like forum and faq plugins all there. However, php with it's all round recent security woes keeps me worried so still exploring the same.

Thanks
HyTC
==================================
Mail Me If Contacting Privately Is That Necessary.
==================================
Quote Reply
Re: [HyperTherm] blog application In reply to
php is a real problem, security wise, and I've said so for years. Perl/cgi is bad enough <G> but by keeping all code out of the webserver space, and making it cgi-bin, parsing scripts and data from secure directories, and such, GT's engine is not only as powerful as PHP, but it's more secure, by far, and builds upon all the _real_ programming work done in PERL.

There's virtually nothing you can't do within a GT template page, with globals, functions, and perl, that you can do with PHP. *AND* all that code in the GT Template, is *not* in the webspace at all. PHP is dynamic, so of course I'm referring to using page.cgi and other scripts to generate output -- not the "static" pages.

PHP started out as a personal-home-page processor, and it caught on, because it _could_ run in the webspace, when ISPs did not want to give cgi-bin access. A user could write a page, end it in .php and it would "run" as a script, without having full cgi-bin access. The security problems were there from the start, and actually built-in on purpose (eg: putting code in the webspace, mixing code/html, and confusing implementation and interface).

php is quick, but it's dirty. It's a "hack" in the truest sense.

If you need security, avoid it, and any scripting language that runs in the webspace.

Just MHO.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [antoined] blog application In reply to
GT has built a custom app for me that serves as a blog for my organization using the GForum plumbing. It essentially pulls root posts in specified forums and formats them using GF templates and is posted as static pages to a different website (http://www.pecupdate.org). They also built a subscription service using templates under GList. While not a true blog per se, but exactly what I wanted/needed to repalce an old newsletter site. The discussion forum (RxNET) restricted, so sorry,no general access. If any of you are interested, I could post some screenshots of the interface, a modifed version of the post template.

We are just ramping up the site, but it looks great Cool!

I believe it was all built as two plugins (GF for web, GL for subscription functions) and templates....so GT may be willing to sell it to others.

Dave
Quote Reply
Re: [bretzke] blog application In reply to
Hi bretzke,

sounds interesting.
- what is actually the difference to the normal GT-forum ?
- some screenshots and explanation what this system does would be great.
- is it possible to use this system as an "events-calendar" where it is possible to sort events by date or location ? or is it better to use G-Links as an event calendar ? How to do this ?


Many thanks,

Erich

Last edited by:

erichcyber: Mar 30, 2005, 12:44 PM
Quote Reply
Re: [pugdog] blog application In reply to
There again:
Quote:
php is a real problem, security wise, and I've said so for years.

PHP 5.0.x
http://secunia.com/product/3919/
PHP 4.3.x
http://secunia.com/product/922/
PHP 4.2.x
http://secunia.com/product/105/

So looks like another upgrade ... :/
Quote:
If you need security, avoid it, and any scripting language that runs in the webspace.

mod_perl enabled applications run in webspace ? suExec and mod_perl don't go hand in hand ... did read something about apache2 and mod_perl2 which is recommended from security point of view ... not too sure though

Thanks
HyTC
==================================
Mail Me If Contacting Privately Is That Necessary.
==================================
Quote Reply
Re: [HyperTherm] blog application In reply to
No,
mod_perl runs in the webSERVER space.
Your cgi files are in a cgi-perl or modified cgi-bin directory.
If a web user makes a request from the the cgi-perl/cgi-bin directory it's *never* served, it's always parsed and served. It's run as a script at all times, and there is no way to serve html or text accidentally from that directory.

PHP is run in the web/html tree. The code is embedded in the web pages. Very often you'll see the code spit out by the server, unparsed. That can be a real security issue.

Also, because the pages are in the html tree, which has general read permissions, a hacker can get more easy access, and potentially upload executable code more easily.

For php to run, your webspace (html tree) has to allow executables or includes.

If you run perl, mod_perl, etc, your webtree can REFUSE to execute any scripts in that space, and your security can be much tigher on the write access to the cgi-bin area, where ALL files are executed, not "served" under apache.

This is an over simplification, but this is why even in the early days, SSI and allowing .cgi in non-cgi-bin directories was strongly discouraged.

PHP was a *major* step back for that (and even put code in the html files!.... which is as bad as putting HTML in the code files!)

Anyway.... problems with perl security are usually due to badly written programs, *not* the compiler or server or "engine" code.

If you stick with a few simple rules of parsing/cleaning all your input, and not taking shortcuts like using the backtick for any user-generated input at all, (I've only used it for scratch files completely generated from internal program input), then you've closed up 99.999% of all findable or obvious holes.

In PHP... it's not so.

PHP was a way to GET AROUND server security <G>. It was for people on servers where the admin did not allow cgi-bin access. It's hard to plug up holes in something that was originally built to be a screen door <G>


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.