help pre-empt head scratching. Will this work ok?

akohl's picture

They have: 117 posts

Joined: Feb 2001

here is a plan for a database interface. Please let me know if there are things here that won't work. Also, I'm open to suggestions as to alternatives that will work better in terms of security, user interface or whatever other relevant aspects.

I'm presenting this outline before ciunstructing the site in hopes that more experienced
developers might save me some "barking up the wrong tree" time.

default.htm;
frameset with two frames on left margin and one main view

nav.asp;
presents login form that posts username and password to
server.checks submitted username and password against database and if they match sends;

1)html code for two select controls defining what user wants to do and which tables he wants to do them to (I want to[view,edit, update,delete][book,user,purchase,publisher]listing)and a button.

2)javascript code onclick of the button stringing together selected values of the two select controls, a switch with 16 cases, each calling a function that will use document.write to present appropriate submit form to dbfunctions.asp in the bottom left margin frame.

dbfunctions.asp;

presents in main view frame another submit form in if neccessary to get values for the database operation, performs data base operation, and presents view of changed listing in the main view frame.

Thanks

Andy Kohlenberg
Jerusalem, Israel

Mark Hensler's picture

He has: 4,048 posts

Joined: Aug 2000

I've written a few admins, and I like the framed layout...

I like to put 'admin sections' on the left frame, and the actual table editing functions on the main (right) frame.

I'm guessing you'll use radio buttons for those options in the left frame? One set of radio buttons for the actions and one set for the tables? I always used textual links for my nav stuff, but I like the idea of using radio buttons...

Will all your users be able to perform all the functions? If not, you'll want to add fields to your username/password table... When they login, check the username/password as usuall, but now check the permissions too. If that user is not allowed a feature (like delete) or table don't print that option in the left nav frame.

Mark Hensler
If there is no answer on Google, then there is no question.

Mark Hensler's picture

He has: 4,048 posts

Joined: Aug 2000

security...

When they login and they are authorized, set a session cookie (like userID). Then on every page check for that session cookie (using an include works best), if it's not there, or it's null (cookie exists, but is blank), or guest (if you'll have a guest level), kick them out to the login page.

If you have a page that only specific people are authorized for, use the session cookie to query your DB and check their permissions. If their authorized for that area, let them in, if not...

Mark Hensler
If there is no answer on Google, then there is no question.

Want to join the discussion? Create an account or log in if you already have one. Joining is fast, free and painless! We’ll even whisk you back here when you’ve finished.