Forms authentication Cookie Monster

[HIK]

I have an ASP.NET application on a Win2k3 server. The user is directed
to form B (with a query string that contains the logon information).
Form B refers to Form A which validates the user according to the query
string. If valid it writes an authentication ticket and the application
returns to form B.

When I browse to the application from its web server, everything works
as expected. The trace showe that Form B is called, then Form A an
authentification cookie is created and then Form B is called again with
the validation cookie in the trace.

If I browse from another computer, the trace shows that Form B calls
form A which forms a valid cookie but the cookie is lost when Form B is
called again. The application goes back to Form A for validation,
produces another cookie, which is again lost when Form A is called
again. This goes on for 4 or 5 repititions until the user gets a "Page
cannot be displayed" error.

(I made a similar post earlier but I can't find it on my client so I
must repost it. I apologize for the double posting).

 

[Guest]

A couple of years ago, I worked on (took over actually) an app that used a
form to submit to a verifyuser.aspx page to determine if a user was valid. It
then returned the information and wrote up the auth cookie. And, the app
failed due to this supreme cluster f___ of bouncing around.

Since the app queried a user store (windows auth), I simply moved all of the
code into global.asax and booted unauthorized users to a page that let them
know they were not welcome. Much simpler.

The reason for the original model: The original designer came from an ASP
background and had not made the ASP.NET methodology change.

So, why are you using two pages?

1. Familiarity with system? Change your thought pattern and write in .NET
2. Reusability of login? Move code to a library
3. Other?

In your app, I see no reason to have form B send to form A via querystring.
I am not saying that there may not be a good reason, only that I am blind to
it. If there is a good reason, then you need to fix the app, as is. If not,
you need to change it.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[HIK]

Cowboy,
I was following procedure recommended by all the asp.net literature, but
I like your "out of the box" thinking. It will be very easy for me to
implement as the code doing the nuts and bolts of the authentification
is in a separate component. I see now its just as easy (and more
efficient) to call it directly from my pages instead of going to the form.

Thanks for your suggestion.

 

[HIK]

Cowboy,
I was following procedure recommended by all the asp.net literature, but
I like your "out of the box" thinking. It will be very easy for me to
implement as the code doing the nuts and bolts of the authentication is
in a separate component. I see now its just as easy (and more
efficient) to call it directly from my pages instead of going to the form.

Thanks for your suggestion.