dlst
01-25-2002, 03:30 AM
This actually isn't a hack request... I've almost completed it. This is what it does:
A client wanted it so that there was a "unified login" to his site. When a user logs into the site, they are automatically allowed entrance to the whole site... they don't have to log in again when going from boards to classifieds.
It works like this (so far):
Registration and login links in the classifieds get redirected to vb login/registration with a $redirect value.
Login/registration in vb is modified to write to the classifieds database with the approprate user info, and it sets the correct cookie info for the classifieds so the user can go back and forth seamlessly.
Since the cookie is set, when they go to the classifieds, they are logged in and can make whatever changes are necessary to the admin panel in that script, independent of vb.
It's tricky... we don't want the user to screw up the data... for example:
What if the user registers in vb, vb sets up the account in classifieds and everything's cool... until the user goes to the classifieds control panel and changes his password... well this would break the system, since vb would have one password and classifieds would have another. What about all the other info?
The way I got around this is by NOT allowing a user to change their password in classifieds (the option is simply disabled). All the other data, they can change, since none of that appears in the cookie, the data integrity between the apps stays clean.
Now granted, a user could have one address set in classifieds, and other info in vb, but on this system, we'll give them the benefit of the doubt.
Vb is further modified to change the classified database when a change to the password is made, and the cookie gets reset, so that pretty much covers logging in and out...
But what about banning? Deleting users?
In this case I'll treat the vb database as the master... there is a utility script that runs on a cron from time to time and "syncronises" the user databases. Actually all it really does is check to see if there are any users existing in the classifieds that for one reason or another don't exist or are not valid in the vb database. If a user is found that shouldn't be there, they are removed according to how the classified script normally handles it.
------
Sorry for the long post... if you're still reading thankyou... and let me know your thoughts. Has anyone had any success or failures with this? I'm sure I'm not the first to try it. Seems easier than writing a classified from scratch.
What a great sister product to vb... a full classifieds that runs of the same structure :). Oh well, visions of sugar plums. For now, I have to jerry rig it.
Also, if anyone cares to poke holes in my logic (disjointed as it is) please do so, it's very much appreciated. It'll save in the debugging and testing stage.
-dlst
ps... I'll start a poll to ask how many people are using a classified script in conjunction with vb, and which one they are using.
A client wanted it so that there was a "unified login" to his site. When a user logs into the site, they are automatically allowed entrance to the whole site... they don't have to log in again when going from boards to classifieds.
It works like this (so far):
Registration and login links in the classifieds get redirected to vb login/registration with a $redirect value.
Login/registration in vb is modified to write to the classifieds database with the approprate user info, and it sets the correct cookie info for the classifieds so the user can go back and forth seamlessly.
Since the cookie is set, when they go to the classifieds, they are logged in and can make whatever changes are necessary to the admin panel in that script, independent of vb.
It's tricky... we don't want the user to screw up the data... for example:
What if the user registers in vb, vb sets up the account in classifieds and everything's cool... until the user goes to the classifieds control panel and changes his password... well this would break the system, since vb would have one password and classifieds would have another. What about all the other info?
The way I got around this is by NOT allowing a user to change their password in classifieds (the option is simply disabled). All the other data, they can change, since none of that appears in the cookie, the data integrity between the apps stays clean.
Now granted, a user could have one address set in classifieds, and other info in vb, but on this system, we'll give them the benefit of the doubt.
Vb is further modified to change the classified database when a change to the password is made, and the cookie gets reset, so that pretty much covers logging in and out...
But what about banning? Deleting users?
In this case I'll treat the vb database as the master... there is a utility script that runs on a cron from time to time and "syncronises" the user databases. Actually all it really does is check to see if there are any users existing in the classifieds that for one reason or another don't exist or are not valid in the vb database. If a user is found that shouldn't be there, they are removed according to how the classified script normally handles it.
------
Sorry for the long post... if you're still reading thankyou... and let me know your thoughts. Has anyone had any success or failures with this? I'm sure I'm not the first to try it. Seems easier than writing a classified from scratch.
What a great sister product to vb... a full classifieds that runs of the same structure :). Oh well, visions of sugar plums. For now, I have to jerry rig it.
Also, if anyone cares to poke holes in my logic (disjointed as it is) please do so, it's very much appreciated. It'll save in the debugging and testing stage.
-dlst
ps... I'll start a poll to ask how many people are using a classified script in conjunction with vb, and which one they are using.