Hi,

Let's recall what we have here. You have user A logged in to your application and then user B on that same workstations gets a user verification link that he clicks on and is logged into the same application, possibly with another vwginstance, correct ?

Your problem is that when user B gets logged in via the verifycation link, then user A continues where B left off, unless you have different vwginstance-s for the two users, correct ?

The problem here is the session level IsLoggedOn. No matter if you created an unauthenticated asp.net page to handle the verification, which is of course possible, then you would still have the problem of either both users are logged in or they both are not, as the IsLoggedOn is session level in 6.3.x.

From what I can see of this, then I think you are not able to solve your problem with the Visual WebGui forms authentication in 6.3.

It might be possible, with smart usage of vwginstance, to make this work with "your own" logon processing, in which case you would not be using the logonform settings in Visual WebGui, rather require authentication on a form level where you would add your own checks in Form.Load where you require user authentication. Keeping the credentials within the form class itself, instead of keeping it in the context or session as you now do, and making sure a new vwginstance is "issued" for each such new request, this should be possible.

What you are effectively doing is disabling the Visual WebGui authentication and making your own, and at the same time you decide on a form per form basis for which forms you require authentication, which should of course be for all forms that are externally available, except for the registration/verification form...

If you do a redirect or Link.Open within your application, you would have to expose those forms via web.config, and in all those forms you would have to beware and make sure no user gets access unless authenticated. This is much harder to do than the Visual WebGui authentication, but it should be possible.

Palli

Hi Derek,

As I understand your suggestion, then you will use one app for the registration/verification and another app for the "main" application.

If using Visual WebGui for the registration app, then from that application, destroying the session just before you redirect to your main application, would make sure the next user doesn't continue where the first one left off. You can always create situations where this might still be questionable, for instance user A clicks the registration link and then user B clicks another link before A completes, then B would get the same screen, unless you make sure each link will have a different vwginstance.

And then of course, if user A logs in to your main app, and then user B gets redirected to your main app, then user B would run under A's credentials as B doesn't get a logon request. You can make sure B doesn't get A's screen/form by using different vwginstance, but B would still be running under A's credentials.

In my experience at work, this is a situation we rarely or almost never get into. That confirms what you say that this will mainly be during development that you have these issues.

Palli

Hi Derek,

The reason is that when you include the "post" prefix, a new context is created. Skipping the "post" prefix, and you will not get that effect, but then again the Load event will not fire either.

Palli