[kdewebdev-site] NewStuff

[Andras Mantia]

On Tuesday 08 March 2005 20:09, Eric Laffoon wrote:
> I've got them too and I've been looking at them. PostGre is a better
> database than MySql but it's somewhat confusing. I've had problems
> even getting it running on my system.

I have it running locally since quite some time. I didn't find hard to 
set up, altough I simply followed some instructions that came with an 
application. But now it's used for two apps here (KMusicDB and 
KBarcode).

> rewriting no matter what. My personal preference would be to use an
> abstraction layer that makes it easy to integrate and change
> databases.

Josef (from kstuff.org) told me that he wants to add such an abstraction 
to his scripts.

> I'm working on the database now. Here is what I need. 
> Andras, can you list the fields you think we will need for the data
> management we've discussed previously?
Probably everything what is in the meta data of the newstuff files plus 
the signature information.

> > KNewStuff also needs the following:
> > - FTP upload possibility: currently this is completely disabled,
> > but we need some FTP or SFTP anonymous or passwordless upload,
> > otherwise uploading won't work at all!
>
> Wrong! George doesn't have FTP enabled for a reason. We can use HTTP
> just as easily. 

Are you sure? I'm not sure that KIO supports HTTP uploading. How do you 
think it should work? We must provide an URL to where things are 
uploaded in the providers.xml, for example:
  <provider 
      downloadurl="http://quanta.kdewebdev.org/newstuff/knewstuff.xml"
      uploadurl="ftp://anonymous@ftp.kdewedev.org/home/kdewebdev/upload"
  </provider>

What would you put in the uploadurl?

> Additionally we have the option to save the file name 
> in the database and put the file in a receiving area or to put the
> uploaded file in the database as a blob.
This is all handled by the way Josef's scripts are working as I 
understood.

>
> Then there is the matter of uploading. This needs to be looked at in
> perspective. Anything uploaded needs to be verified that it is not
> some form of exploit for security reasons. Right? 

Right. This is why the upload area is completely different from the 
download one and Josef even suggests that the upload directory is 
writable, but not readable from outside. 

> After all someone 
> could introduce a toolbar with a button script of "rm -Rf ~/*". I
> thought we discussed digital signatures and such? Here are some
> options...
>
> 1) allow anonymous uploads - assuming the administrator is not
> overloaded this could be okay but I think it's not the best at all

The script run by the cron job could check from time to time the 
anonymous uploads and based on the signature could determine if it is 
safe to put the resource immediately available for download or should 
be reviewed.

> 2) Set up to allow passwordless uploads through user cookies which is
> very easy if we're using HTTP.

In this case I think we can forget the upload from the application 
unless you prove me that it works.

> > - possibility to add cron jobs, otherwise the automatic scanning of
> > uploaded files will not work. cron jobs are needed as well if we
> > choose to update the web pages from CVS.
> >
> > Andras
>
> cron jobs are easy enough to do, but my idea is that only trusted
> members would have their packages put up automatically. 

Sure, but the cron job would also move the files from the upload server 
to a review queue.

> To become 
> trusted you would have to be granted this status from a developer or
> you would need an upload record that had met certain statistical
> criteria to be automatically set as trusted.
Right, but this is about what kind of automatization we do on server 
side, not how we get the resources from the users.

Andras
-- 
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://momo.creolmail.org/pipermail/kdewebdev-site/attachments/20050308/167ffc36/attachment.pgp