Using Member API & WWF Login simultaneously

I've been playing around with having both the member API and the regular WWF login system running side by side and it's been working near perfectly.
My setup is basically the following:
I'm running Rainbow portal with WWF.
I have 2 kinds of users:
1) Special users, who have Rainbow logins - they're the ones who will be using the member API to be auto logged in to WWF.
2) Pure WWF users, who will register and login ONLY through WWF.

The special user registration won't be open to the public - the special users will be created mostly by me before the site is launched, with the possibility of a few more being added by the site owner.

The only problem I've come up against is when a special user (who already has a corresponding WWF login) browses to the site with a new password.
Let's say in Rainbow my username is John and my password is cat. When I browse to WWF for the first time, a user profile is auto created for me with those details.
If I close the browser, clear cookies, and then visit WWF directly (without logging into Rainbow first), I can successfully log into WWF manually using that same username and password. That's great.

However, if I change my password (in Rainbow) to dog, things get confused. When I browse to WWF I still automatically get logged in fine, despite the new password (this is a feature, I know).
But this time, if I close, clear cookies, and come back to WWF directly - these login details no longer work. In fact, neither cat nor dog would work a password.. and since the passwords are encrypted one-way in SQL, I have no way of knowing what it's set to now!

I admit that I haven't delved into the functions_member_API.asp code to try to figure this out as yet.. but does anyone have any idea to what may be happening (and how I can overcome it?)

Oh, and one other question..
When member API users click the logout button in WWF, they instantly get re-logged in because the forum login cookies are still set.. is there a way to 'kill' cookies by name upon logging out?

Thanks a bunch for reading everyone.. Web Wiz is great!

Cheers,
John.


Edited by kanun - 08 June 2006 at 10:05pm

Thanks for your reply.

-boRg- wrote: The member API was never designed to be used in the way you are, it was designed that if the member API is enabled the forums own login system is disabled. This is done because there are quote allot of issues that will course problems if you run the two systems side-by-side.

I see.. Given that I've tested logging in both ways and it seems to work pretty well, do you still think it is a bad idea to have both work together? Do you reckon that even though it seems fine on the surface, I'd eventually find a bunch of deeper problems?

When using the member API, when a user changes their password in your own login system you need to update the Session("PASSWORD") = "" variable with the new password so that this can be carried across to the web wiz forums and be updated in the forum.

This is indeed the case, but the problem still remains. I can tell for sure because I used Response.Write(Request.Cookies("")) in default.asp to show me the values of the session cookies - and the new password is getting read into WWF - if it wasn't, I wouldn't have this problem.

As to your last question, to 'kill' cookies on log-out, try adding the following line to the file log_off_user.asp:- Response.Cookies(strCookieName)("UID") = ""

Yep, tried that and it worked fine!

Cheers,
John

Thanks for replying Borg, I appreciate your help in this matter.
The reason I'm going to go along with this anyway, is because the portal user accounts that need the member API are going to be controlled (not registerable through website) and practically static. Any new portal accounts will be manually created by the webadmin, who can just create a corresponding WWF account manually anyway.

So my plan is to go ahead with the side-by-side setup, and find ways of getting round these issues.

Thanks again, and if anyone's interested I'll gladly share my experience trying to get it running.

John.

Will do!