Gossamer Forum
Home : Products : Gossamer Links : Version 1.x :

Wishlist / wantlist

Quote Reply
Wishlist / wantlist
Alex,

These are things in no particular order. Because of the nature of SQL, and that you simply can't tack fields onto the end of links.def some utilties are really needed.

The more flexibility that's coded in now, the easier it will be to add/modify the programs later.

Some of these things may sound simplistic, or obvious, but answers will help everyone.

1) backup/restore database -- in the works
-- the ability to chose the back up rotation schedule as previously discussed.

2) add a field to a table -- needs to be a complete solution, in that the field is properly added to all places it needs to be -- and how to make it useable in templates if all variables are not available by default.

3) modify a table (if necessary create new table --> copy old table --> drop old table --> rename table or re-add old table and copy then drop new table)

4) fields I'd like to have added to the category database:
a) short description (used home page/sub page)
b) long description (used on category pages/links pages)

5) ability to make Page 1 of any category/span pages different from subsequent pages. ie: put the long description, hints, help on the first page, and short description on the next pages.

6) file upload -- integration with a program like your fileman, to upload files and graphics and have their size, and other data added to the database automatically. Ideally you can pick the upload area, but putting the graphics in an 'upload' area until validated (like old BBS systems). (I'm working on a kludge to let me do this my way, but it has some general appeal in the area of logos, banners and other forms of graphics (status). If you are interested, I can point you to some very good source code for graphics I've found).

I don't know what else you have on the burner, but the 3-level new mod because it's so popular, and the bug fixes, and backup are certainly at the top.

I know you are working on efficiency algorithms, but MAINTENNANCE UTILITIES for the SQL end are very, very important. A site grows, and doesn't only add new links. Every so often, to remain competitive, a new field to the database has to be added.

Please also keep a very detailed list of changes you make to the program -- even a small change may affect some modification we have made.

Especially now, when the program is still actively growing/changing, your additions and fixes have to be worked into our modifications.

LinkSQL will undergo some major revisions in the near future, it's inevitable. Please take the time to document your changes in the changes.txt AND in the code! Comments can always be stripped out for speed, but they are invaluable to us, your users.

Thanks... and keep it up!! Smile
Quote Reply
Re: Wishlist / wantlist In reply to
More wishlist Smile

1) Allow the "rate" page to have a bit more flexibility in the config file. Allow changing the Top 10 to any number, and allow absolute hits vs average hits per day.

2) A configuration front end, like UBB or UltraScripts. Would probably solve a lot of the customer support issues and installation issues.



------------------
Robert S. Pataki, MD
President, PUGDOG Enterprises, Inc.
http://www.postcards.com
Quote Reply
Re: Wishlist / wantlist In reply to
Thanks for all the great suggestions! I'll be sure to implement a lot of them, especially on the supporting tools side (we are working on a table editor to edit your .def online and automatically update/adjust mysql).

Cheers,

Alex
Quote Reply
Re: Wishlist / wantlist In reply to
Some of the features were added with 1.02, but as a reminder (from another thread) the "create table" feature would be nice. _ALSO_ a way to re-write the .def to reflect what the database _really_ looks like. This is a valuable feature, since manually making mods can introduce inconsistencies (as can accidentally updating with older versions from backups or work areas).

The 3-level-new/updated mod, or x-level-new/updated mod is really something I want, and I know others do. The larger the database gets, the more important visual flags are to the users.

Maybe changing the "isNew" field from a Yes/No to "Null/0" or "Int" That way it would still pass "if" tests on whether it had a value or not, but also could be looked at to see what the value was, and acted upon accordingly.

Integrate search/keyword logging into the program so it can be turned on/off from the config menu, and a list of "Top Searches" can be returned, with the count of popularity, and/or expected 'hits' This could be returned via keywords.cgi since it's a simple table look up and output, overhead should be low.

"Modify" to do a search on the 'existing' URL, and if found, return a form with the values to be changed, and unchangable values simply printed as HTML/text (not in input boxes). There's no reason to present people with all the boxes, if the URL doesn't exist, and then to force them to retype it. If the URL doesn't exist, it bounces to the "add.cgi"

This would also be the first step (framework) to allow internal passwords for people to be able to edit their own entries, and would be relatively simple to implement with a new database field if someone wanted it.

Security:
The database log ons are stored in each of the .def files, as plain text.

Is there a way for that to be stored with some rudamentary encryption?

Is there a way for that to be put into an "include" file, so it can be changed once for all files?

Multiple admins can be relatively easily implemented using MySQL built in security, as long as the database log-on isn't root. If the Admin screen asks for the database log on, rather than assuming it, then there is built-in security beyond .htaccess

LinkSQL doesn't have to actually implement the security levels, since in all honesty, this could be left to the MySQL Admin root user to set up. (In otherwords, user set up doesn't need to be within LinkSQL, as long as LinkSQL acts on the user permissions set up.)

Additional security would be available with things like: Modify and Add would have read access to the Links table, but read/write acces to the Validate table. Search needs _only_ read access to the tables, but read/write access to the Search_Log table if enabled.

As a database moves beyond 2-3,000 links, the need for multiple admins, and limitations on the security/access levels they have is more and more important.

At 25,000 and more it's essential.

MySQL has a multi-layed and down-to-the-column level security system already built in.

Just a few more suggestions/ideas.


Quote Reply
Re: Wishlist / wantlist In reply to
splitting up the Edit Category Relations screen http://www.gossamer-threads.com/...um9/HTML/000007.html
Quote Reply
Re: Wishlist / wantlist In reply to
Thanks for the feedback! Just some comments on the security side of things:

Quote:
Is there a way for that to be stored with some rudamentary encryption?

Yes, but I'm not sure how worthwhile it would be. Anyone who had the source to Links SQL could figure out how to unencrypt them as the passwords need to be passed to the databse unencrypted. Most likely anyone who can see the .def files can also see your Links SQL source.

Also, you should definately make sure mysql is setup to only allow access from the local machine.


Quote:
Multiple admins can be relatively easily implemented using MySQL built in security, as long as the database log-on isn't root. If the Admin screen asks for the database log on, rather than assuming it, then there is built-in security beyond .htaccess

I'm not sure what you mean here. Do you mean multiple admin's who all have the same access? Or multiple admin's, each managing a section of the directory?

Cheers,

Alex
Quote Reply
Re: Wishlist / wantlist In reply to
 
Quote:
I'm not sure what you mean here. Do you mean multiple admin's who all have the same access? Or multiple admin's, each managing a section of the directory?

I mean multiple admins with different access levels.

Right now, the admin logs on as the general user with full privs. I have problems with the log-ons being hard coded anyway.... It's a real security problem. "read" access to the databaes, or write access to the Validate table is reasonable, but there is no reason the same password has to be used for all scripts.

What should be implemented is an input-password, and that password is used for all transactions during that session.

The default admin password should give 'read' access to the tables. An admin or editors password needs to be entered to allow additional access.

This is part of MySQL. All LinkSQL has to do is handle the password properly.

For simplicity sake, the current implementation can be the default implementation. But, for those who want to implement a higher security, and can deal with the MySQL priv tables on their own, the ability to use a supplied rather than default password should be added.

Now, I know this can cause problems down the line, since the routines are set up to modify records, not columns, but I see this as a necessary migration.

First, allowing a supplied password.

Then, with process_query the editor privs are checked, and only the fields that are able to be modified are updated so the query doesn't fail with an error.

LinkSQL has to handle the privs, but not the security... that's in MySQL. If the password is wrong, the command will fail. LinkSQL has to generate the proper query and handle errors if a request fails to report bad password or improper fields.

Quote Reply
Re: Wishlist / wantlist In reply to
I wouldn't want to force the security down to the mysql level, as it prevents doing things like giving access to a user to modify only the Business and Economy links.

I think Links SQL should handle the security. What I have planned is leaving the admin as is, but creating an editor.cgi which will require authentication and provide a person with limited access to the Links SQL database.

Cheers,

Alex