PHP Login: Restrict New Member Registration

[dmarks2061]

Hi folks. I've been implementing a login system for a client using the PHP Login tutorial Ben Falk did. The problem is, I don't want just any member to be able to add a new member; that should be reserved for the admin. But I can't figure out how to restrict the option based on user name.

 

I've added a line to the v_members.php file to test the operation. It looks like this:

 

if ('admin' == 'admin')

{

echo '<form action="register.php" method="">

<input type="submit" name="submit" class="submit" value="Add User">

 

 

which works fine. Now I need to replace the first argument ('admin') with the member name entered. I've played around with "username", $input['username'], $_POST['username'], etc. but haven't figured out how to do this.

 

Any suggestions would be appreciated. Thanks!

 

DMarkS

[dmarks2061]

OK, never mind. I just started throwing variables out there and checked the output till I got the one that works. Heck of a way to learn a language, eh?

 

So the winning combination is:

 

if ($username == 'admin')

{

echo '<form action="register.php" method="">

<input type="submit" name="submit" class="submit" value="Add User">

 

Sometimes it takes a posting to get the brain to working. Ciao!

 

DMarkS

[falkencreative]

If you look at parts 17/18 of the series, I discuss creating basic permissions to deal with this issue. Have you watched those two videos?

 

What you have above works, but perhaps a more efficient way to do it is discussed in the videos. Basically, I add a "permissions" field to the members table, which holds a value that indicates the user level (admin, user, whatever). When the user first logs in, I grab the permissions setting from the database and save it in a session variable. If I want to restrict the user based on the user level, I can check the session variable that I set.

[dmarks2061]

Hi Ben; thanks for commenting. No, I haven't watched those videos yet. I scanned the subjects, but didn't connect the general topic of permissions with the specifics of controlling views. DOI! I'll check the videos out, and I appreciate the pointer. Take care!

 

Mark___

[kraxzy]

OK, never mind. I just started throwing variables out there and checked the output till I got the one that works. Heck of a way to learn a language, eh?

 

So the winning combination is:

 

if ($username == 'admin')

{

echo '<form action="register.php" method="">

<input type="submit" name="submit" class="submit" value="Add User">

 

Sometimes it takes a posting to get the brain to working. Ciao!

 

DMarkS

 

A quick note, if you are gonna use this live on the net, please spend some time making the code more secure. A potential black hat would nail the variablename and the value within his/her first tries of variable injections, which would bypass your security rendering it useless.

[falkencreative]

A potential black hat would nail the variablename and the value within his/her first tries of variable injections, which would bypass your security rendering it useless.

Perhaps you can explain this more? Any links on the subject? I can understand that someone may be able to change the variable if it comes from a $_GET/$_POST/$_REQUEST... (I am also assuming that register_globals is off.)

[kraxzy]

Perhaps you can explain this more? Any links on the subject? I can understand that someone may be able to change the variable if it comes from a $_GET/$_POST/$_REQUEST... (I am also assuming that register_globals is off.)

 

From the go php engine doesn't allow direct access to it, if it hasn't been redirected by the webserver. However there are often other codes in combination that we tend to use that unwillingly impose threats very easily used by people with bad intention.

 

Let say you got any other php function utilizing the eval() function, like include, ínclude_once, require, require_once and so on. What you then do is, generate a server side error getting the php version if lucky, or spend some extra time getting hold of that, google all known code inject vulns associated with eval() php for that version and down. And as often is the case you the vuln is still active on so many places. Then simply load in your own snippet of code among the stuff already there.

 

And lets face it too many are using includes without securing basedirs and basepaths.

 

Thinking anything is secure is a wrong move, you need to assume everything is unsafe and take every possible step in preventing it from being easily taken advantage of.

 

I assume you guys have at some point taken the PHP certificate, just remember the security part of it, pretty much all the things you should look out for is still around today.

[wjohn]

Kraxzy can you give an example of how to secure basedirs and basepaths?