I have a membership database and I am wanting to set it up to allow those who register to see the short view (list of registered names) - however in order to view the Long Record (Names/info) you must be granted member access.

Has anyone came up with a way to do this?
--------------------------
donm

This would require another type of permission, if I'm understanding you correctly. I remember trying that about a year (or more) ago and I couldn't get it to work.

We could try it again, if you want to go through it.


------------------
JPD

I would really like to try and get this to work if you have some time and wouldn't mind trying to walk me through it.

-------------------------
donm

Okey-dokey. I'm going to have to get my brain set for this, so I'll start on it after I've had some sleep.

My suggestion is that you copy all of your files and put the copies in a new directory on your site. You'll also have to adjust the .cfg file a little. I just want to make sure that nothing gets corrupted in your files as we're working on this. I know your database is up and running and we wouldn't want anything to happen to it.


------------------
JPD

OK Carol - no problem. Get as much rest as you need ! :-)

I already have the files in a different directory and ready to go.

Thanks alot for your help !
----------------------------
donm

Okay. We're gonna have to take this in small steps and test each one out as we go.

First, replace your .pass file with the following:


Change the "guest" permissions to match the permissions you want to give to registered users. Notice that there is an extra field in there from the original, just before the admin. That is the "member" permission.

In $auth.pl, sub check_password, change


to


and change


to


and change


to


In db.cgi, sub main, change


to


In html.pl, sub html_home add a print statment somewhere on the page where you will be able to see it


Upload the files and login with each of the usernames. You should get the following:

When logged on as admin:
Member -- 1

When logged on as author:
Member -- 1

When logged on as guest:
Member -- 0

(It's possible when you log on as guest that you will get

Member --

but that's okay, too.)

Lemme know what happens.



------------------
JPD

Ok Carol - that worked out just fine. I receive the following:

admin:
Member -- 1

author:
Member -- 1

guest:
Member -- 0

Next step? :-)

-----------------
donm

Excellent! Now to apply the permissions to new signups.

In your .cfg file, change the

@auth_default_permissions

to

(1,0,0,0,0,0)

(Basicly, we're just adding a permission level here. Keep what you have, but add another ,0 to the end.)

Same thing with

@auth_signup_permissions

since those who just sign up online will not be considered members.

You're using the secure password lookup, right? (Or at least one of the lookup mods that includes the email address in the .pass file.) If so, in db.cgi, sub signup, change


to


and change


to


If you're not using a password lookup mod (and for those who might be following along who aren't), you won't have to change anything in sub signup.

Now upload your .cfg file and your db.cgi file. Go to the login form and sign up for an account. Log in with the new username and password and see what you get. It should be

Member -- 0

or

Member --

Next, download the .pass file and change the permission to 1 for the new user. Upload the .pass file and log in again as the new user. You should get

Member -- 1

The next step will be changing permissions through the admin display.




------------------
JPD

Ok ... everything is still working just as it should.

(oh and BTW - yes, I am using the Secure Password Lookup)

Next Step :-)

-----------------
donm

[This message has been edited by donm (edited April 09, 2000).]

This is going great! I wonder why I couldn't get it to work before.

For anyone that's reading along who does not have the secure password lookup mod installed, the next section will be different for you. If you need the code for the regular "non-lookup" script and can't figure it out from readin this, just ask.

In db.cgi, sub admin_display

change


to


(This line appears twice -- once when creating a user and once when updating a user. Be sure to change it in both places.)

and change


to


and change


to


and change

[I seem to have left out something the first time around]


to


Now login as admin and change the permission for the user you added in the previous step. Change him to a non-member. Then exit and logon as the user and check the permission. Then logon as admin again and change the user back to a member. Once more log on as the new user and check the permission.

One other thing. Do take note of the other permissions to make sure nothing has changed with them. There shouldn't be a problem, but one never knows.

This is just about done. If all this works, the only thing we'll need to do is set up your current .pass file (no small task! ) and then you can use the permission as you want to.

I do want to thank you for your patience in this, Don. It's a lot easier to work things through one step at a time. Even if there's not a problem with any step, it really helps me to go in little bits rather than trying to see the whole thing at once.



------------------
JPD








[This message has been edited by JPDeni (edited April 09, 2000).]

[This message has been edited by JPDeni (edited April 09, 2000).]

Oops. I forgot something. The lookup part. There are a number of things to change here. If you feel lucky, go ahead and make all the changes at once. If you are cautious like me, change the code in one subroutine and test it before you change the code in the next subroutine.

In db.cgi, sub lookup, change


to


and change


to


and change


to


---------------
If you're using sub get_email, you'll need to make some changes there, too.

Change


to


and change


to


---------------
If you're using sub change email, make the following adjustments:

Change


to


and change


to


and change


to


and change


to


---------------
If you're using sub change_password, make the following adjustments:

Change


to


and change


to


and change


to




------------------
JPD

OK - we are now encountering our first problem. After making all of the above changes. We have lost admin permissions.

When clicking on the "admin" link - I receive "Unauthorized Action".

Also - I noticed in the changes you have this line:
Shouldn't one of the $in{'per_mod'} be $in{'per_mem'} ?

Oooops you posted before I had a chance to respond LOL. I mean the changes before your last post here.
---------------
donm


[This message has been edited by donm (edited April 09, 2000).]

Yep. You caught the error I made before. You are absolutely right. I'll go back and make that change after I finish answering this. (See what happens when I go too fast? )

I'll go back over sub admin_display and see if I can find somewhere else that I need to change.





------------------
JPD

Check the .pass file and see if the 1 for "admin" is gone from the permission. That will help tell me if there is a problem with reading the file or with writing to it.


------------------
JPD

No - the "1" for admin is still there.

I did see one possibility. There are two instances of the line:


that you need to change to


I'm not sure if that would cause the problem or not. That's the only thing I can see. Give that a try and let me know what happens.


------------------
JPD

OK - I found 5 instances of that line in db.cgi and changed them all still no luck with "admin" - I still receive "Unauthorized Action" when clicking on the admin link.

-----------------
donm

Can you post your .pass file so I can get a look at it? (I don't think there will be a problem with security, since the passwords are encrypted. And you can always delete it after we're finished.)


------------------
JPD

Sure I can - it's a test database anyway....(didn't wanna try this on my "live" database's yet) nothing in there as of yet except dummy accounts.

BTW - thank you for your patience with my lack of Perl knowledge... I am learning alot though. This is one thing though that I was not ready to try and tackle alone.

-----------------------
donm

You're welcome. This is obviously a tough nut to crack anyway.

Your password file looks okay.

Try this. Add some more debugging lines to sub html_home.


Login with all the usernames and see what you get. (I probably should have had you do that in the first place so we could keep an eye on things.)



------------------
JPD

ok after adding the above code to sub html_home - this is what we have:

donm77 - view-1, add-1, modify-1, delete-1, member-1, admin-1
Admin - view-1, add-1, modify-1, delete-1, member-1, admin-1
Author - view-1, add-1, modify-1, delete-1, member-1, admin-0
Guest - view-0, add-1, modify-1, delete-0, member-0, admin-0
test1 - view-0, add-1, modify-1, delete-0, member-1, admin-0

----------------------
donm

I don't understand. If you have $per_admin for your user, why wouldn't it-- wait a minute.

I know.

In auth.pl, sub auth_check_permissions, change


to


and change


to


That oughta do it. (Minor detail. I had taken care of the permission when the user logged in, but not when they actually tried to do something. )



------------------
JPD

OK - admin is now working. However, when I tried to change the permissions on the test1 account through the Admin Panel - this is what happened:
As you can see it corrupted the test1 account.

BTW - before changing test1 - I noticed in the admin panel that test1's email address was also missing and was replaced by a "0".

-----------------------
donm

Oops! That isn't good.

Let me look over it again and see what I can come up with. I'll post as soon as I come up with something.


------------------
JPD

For some reason in the admin panel - it is pulling some sort of permission in the form of a "1" or "0" depending who you are logged in as and placing it in the email field.

----------------------
donm