Re: [Phpslash-devel] setup.php

[Mike G. <mi...@op...>]

Hello Again,

<just snipping some stuff>

On Tue, 2003-03-18 at 22:39, Luis M wrote:
> >This is just my 2c on this issue.  But I would think that the easiest
> >thing from the user perspective would be to:
> >1) check to see if the config.ini.php has write permissions
> >a) if so write to directly to the file (with confirmation)
> >if(is_writeable{config.ini.php})
> >
> >b) if not send the config to the user via:
> >header ("Content-type: application/txt\nContent-Disposition: inline;
> >filename='config.ini.php'");
> >
> >Think that this is valid, I had it as
> >application/csv\nContent-Disposition previously.
> I will experiment using different headers on different browsers to see what 
> happens, but I know it will work for all browsers (even lynx) if one only 
> allows the file to be presented as HTML and then let the users save it 
> locally. 

Adding browser detection for those odd browsers like lynx is an
interesting and admirable idea.  Can you edit a phpSlash site with
Lynx?  That would be pretty funky.  However most folks who use lynx and
would also be setting up phpSlash would probably be pretty hard core
folks and pretty darn familiar with vi.

But for folks with visual disabilities, would be interesting to see how
little one could get away with..

> Joe didn't want to deal with writing the file to the server because 
> of permission issues and just more questions to the FAQ from newbies.
> My idea of a setup.php is to be as easy as possible on newbies, hardcore 
> phpslash users will go their way with their vim's or emacs. Of course, if we 
> get the setup.php right, then core users could run the initial setup.ini.php 
> thru the setup.php first (just for convenience) and then if needed edit it 
> later by hand (to add extra features).

Security...  Seems like such a drag until someone busts in and destroys
a site you've spent months working on.

However, hopefully phpSlash will start to attract folks who are looking
to 'upgrade' from phpNuke.  Would be good if an install were as simple
as possible to get off the ground.  Securing it after that so that
no-one can do any damage is the trick and I can't say that I know enough
about this..  Just keep looking for a crisper solution to move us closer
to a fool proof install.

> > > Save this resulting file as Plain Text, and
> > > give it a valid name "setup.ini". Of course the user will put this file
> > > OUTSIDE of the web server space, thus there is no need to add the "; 
> ><?php
> > > die() " lines ... but, to be safe, we could add those lines regardless.
> >For security, the config.php could check to see that setup.php has been
> >deleted before allowing the user to log in.  This way they could see
> >that its working and then delete it. either or both of these could be
> >used to add security to make sure someone else can't edit the config
> >afterwards.
> >if(is_file(setup.php))
> >if(is_writeable{config.ini.php})
> Well, setup.php is harmless if it only allows the config-dist.ini.php file 
> to be used. It's only when we start allowing users to pass arguments with 
> their own files that the problems start getting complicated. At that point 
> we might just check first that there is a valid instalation of phpslash 
> (checking if setup.php is loadable and using the login stuff to get the 
> users to login with a valid username/password)... but that's a lot more than 
> what is needed... we only need a simple way to get phpslash setup the first 
> time -- with newbies and Mac users in mind :-)

Agreed..  Folks who are upgrading are already more committed to the code
than someone downloading it for the first time to check it out.

> > > The reason I did this is because sending a header to the browser that 
> >this
> > > file is type text/ini or text/whatever, might cause the browser to 
> >display
> > > the file anyway. So the "save file" would not do what it's supposed to 
> >do.
> >
> >True..  But its also another step for a user to go through..  What
> >browsers would mix up the header?
> :-) it's just a matter of testing browsers to see what works for all :-) or 
> adding an extra step and skip the testing part...

Both take time....

> > > I added other minor enhancements. I plan to allow the users to "preview" 
> >the
> > > file and possibly feed it back to the same form to be re-edited... but
> > > that's in the future.
> >Only so much time..  Does the script populate the database or just write
> >the config.ini.php for you?
> it might be nice to get to that point, but for now is just to get a .ini . I 
> think that populating the database will get us in a whole different mess: 
> users will have to definitely remove the setup.php file from their 
> instalations when finished, users will have to provide the .sql file they 
> want/need according to whether they are upgrading or are setting phpslash 
> for the first time, etc...

Yes...  It's certainly more complicated..  Ideally there'd be some way
to just grab a piece of the phpMyAdmin script so that after creating the
ini that the script check that it has proper permissions to the db,
checks to see if phpSlash tables exist to upgrade, and if there aren't
tables there to upgrade, grabs the slash-all.sql and populates the
database (much like it would if you just cut & paste it into the
phpMyAdmin text area box).

Unfortunately when I tried to do this with phpMyAdmin, I found the code
wasn't modular enough for me to do this very easily....

But that's a ways off I suspect.

> talking about upgrading, it would be nice to pick the settings from the past 
> config.php3 files for those users... but then again, that's another big mess 
> :-) i'm just trying to keep it simple.

Probably best..  Get something working that everyone can agree on.. 
Then if there's time & interest make it better..

Mike
-- 
Mike Gifford <mi...@op...>
OpenConcept Consulting http://www.openconcept.ca