We have a working application which uses Server session variables as a
means to identify the user.

My boss want to start looking at the IIS logs to understand what our
users do. On our website we have occasional users and also customers
for which we have an ID. We would like to be able to link IIS log data
to internal data via the customer ID, even when we know it is not the
100% of our users.

I'm not sure if I should replace the Session("CustomerID") for a
MySession("CustomerID") that also writes a Cookie which will in turn
be logged in IIS. Or write the ASP.NET_SessionID along with our
CustomerID to a table in the database. And if I do should I mess with
the current page inheritance or just make the call like
MyLib.MySession(Me, "CustomerID") .

For security reasons I just don't want to use an ID returned from a
browser.

Has anybody dealt with this? Will sombody come forward and give a
suggestion? Please?

On May 26, 12:14 am, arthernan <arther...@hotmail.com> wrote:
> We have a working application which uses Server session variables as a
> means to identify the user.
>
> My boss want to start looking at the IIS logs to understand what our
> users do. On our website we have occasional users and also customers
> for which we have an ID. We would like to be able to link IIS log data
> to internal data via the customer ID, even when we know it is not the
> 100% of our users.
>
> I'm not sure if I should replace the Session("CustomerID") for a
> MySession("CustomerID") that also writes a Cookie which will in turn
> be logged in IIS. Or write the ASP.NET_SessionID along with our
> CustomerID to a table in the database. And if I do should I mess with
> the current page inheritance or just make the call like
> MyLib.MySession(Me, "CustomerID") .
>
> For security reasons I just don't want to use an ID returned from a
> browser.
>
> Has anybody dealt with this? Will sombody come forward and give a
> suggestion? Please?

The first approach with a cookie is the easiest and quickest, I think.

On May 25, 5:37 pm, Alexey Smirnov <alexey.smir...@gmail.com> wrote:
> On May 26, 12:14 am,arthernan<arther...@hotmail.com> wrote:
>
>
>
>
>
> > We have a working application which uses Server session variables as a
> > means to identify the user.
>
> > My boss want to start looking at the IIS logs to understand what our
> > users do. On our website we have occasional users and also customers
> > for which we have an ID. We would like to be able to link IIS log data
> > to internal data via the customer ID, even when we know it is not the
> > 100% of our users.
>
> > I'm not sure if I should replace the Session("CustomerID") for a
> > MySession("CustomerID") that also writes a Cookie which will in turn
> > be logged in IIS. Or write the ASP.NET_SessionID along with our
> > CustomerID to a table in the database. And if I do should I mess with
> > the current page inheritance or just make the call like
> > MyLib.MySession(Me, "CustomerID") .
>
> > For security reasons I just don't want to use an ID returned from a
> > browser.
>
> > Has anybody dealt with this? Will sombody come forward and give a
> > suggestion? Please?
>
> The first approach with a cookie is the easiest and quickest, I think.

OK, let's assume I do, Should I code it like MyLib.MySession(Me,
"CustomerID") and avoid dealing with inheritance. Or should I code it
MySession("CustomerID")

On May 29, 6:50 pm, arthernan <arther...@hotmail.com> wrote:
> OK, let's assume I do, Should I code it like MyLib.MySession(Me,
> "CustomerID") and avoid dealing with inheritance. Or should I code it
> MySession("CustomerID")- Hide quoted text -
>

I think all what you need is to set a cookie

Response.Cookies["CustomerID"].Value = Session["CustomerID"];

Note, you will need a reporting tool which could read that values from
the IIS log.

On May 29, 1:37 pm, Alexey Smirnov <alexey.smir...@gmail.com> wrote:
> On May 29, 6:50 pm,arthernan<arther...@hotmail.com> wrote:
>
> > OK, let's assume I do, Should I code it like MyLib.MySession(Me,
> > "CustomerID") and avoid dealing with inheritance. Or should I code it
> > MySession("CustomerID")- Hide quoted text -
>
> I think all what you need is to set a cookie
>
> Response.Cookies["CustomerID"].Value = Session["CustomerID"];
>
> Note, you will need a reporting tool which could read that values from
> the IIS log.

It's just easy to miss. I'd like something more foolproof.

On May 29, 9:56 pm, arthernan <arther...@hotmail.com> wrote:
> On May 29, 1:37 pm, Alexey Smirnov <alexey.smir...@gmail.com> wrote:
>
> > On May 29, 6:50 pm,arthernan<arther...@hotmail.com> wrote:
>
> > > OK, let's assume I do, Should I code it like MyLib.MySession(Me,
> > > "CustomerID") and avoid dealing with inheritance. Or should I code it
> > > MySession("CustomerID")- Hide quoted text -
>
> > I think all what you need is to set a cookie
>
> > Response.Cookies["CustomerID"].Value = Session["CustomerID"];
>
> > Note, you will need a reporting tool which could read that values from
> > the IIS log.
>
> It's just easy to miss. I'd like something more foolproof.

What would make it more foolproof?

When you save a cookie, the cookies will be logged in IIS log among to
other data, making them available together to be used in your
reporting. If you gonna save that CustomerID somewhere else, like in a
database, you will have a problem to link the ID and IIS log.

On May 29, 3:05 pm, Alexey Smirnov <alexey.smir...@gmail.com> wrote:
> On May 29, 9:56 pm, arthernan <arther...@hotmail.com> wrote:
>
>
>
>
>
> > On May 29, 1:37 pm, Alexey Smirnov <alexey.smir...@gmail.com> wrote:
>
> > > On May 29, 6:50 pm,arthernan<arther...@hotmail.com> wrote:
>
> > > > OK, let's assume I do, Should I code it like MyLib.MySession(Me,
> > > > "CustomerID") and avoid dealing with inheritance. Or should I code it
> > > > MySession("CustomerID")- Hide quoted text -
>
> > > I think all what you need is to set a cookie
>
> > > Response.Cookies["CustomerID"].Value = Session["CustomerID"];
>
> > > Note, you will need a reporting tool which could read that values from
> > > the IIS log.
>
> > It's just easy to miss. I'd like something more foolproof.
>
> What would make it more foolproof?
>
> When you save a cookie, the cookies will be logged in IIS log among to
> other data, making them available together to be used in your
> reporting. If you gonna save that CustomerID somewhere else, like in a
> database, you will have a problem to link the ID and IIS log.- Hide quoted text -
>


OK, I did not make mysefl clear. The line:

Response.Cookies["CustomerID"].Value = Session["CustomerID"];

Could be easily missed during programming. We don't have a strong
testing team here, and we would en un with pages that are not being
tracked

On May 29, 10:10 pm, arthernan <arther...@hotmail.com> wrote:
> On May 29, 3:05 pm, Alexey Smirnov <alexey.smir...@gmail.com> wrote:
>
>
>
>
>
> > On May 29, 9:56 pm, arthernan <arther...@hotmail.com> wrote:
>
> > > On May 29, 1:37 pm, Alexey Smirnov <alexey.smir...@gmail.com> wrote:
>
> > > > On May 29, 6:50 pm,arthernan<arther...@hotmail.com> wrote:
>
> > > > > OK, let's assume I do, Should I code it like MyLib.MySession(Me,
> > > > > "CustomerID") and avoid dealing with inheritance. Or should I code it
> > > > > MySession("CustomerID")- Hide quoted text -
>
> > > > I think all what you need is to set a cookie
>
> > > > Response.Cookies["CustomerID"].Value = Session["CustomerID"];
>
> > > > Note, you will need a reporting tool which could read that values from
> > > > the IIS log.
>
> > > It's just easy to miss. I'd like something more foolproof.
>
> > What would make it more foolproof?
>
> > When you save a cookie, the cookies will be logged in IIS log among to
> > other data, making them available together to be used in your
> > reporting. If you gonna save that CustomerID somewhere else, like in a
> > database, you will have a problem to link the ID and IIS log.- Hide quoted text -
>
> OK, I did not make mysefl clear. The line:
>
> Response.Cookies["CustomerID"].Value = Session["CustomerID"];
>
> Could be easily missed during programming. We don't have a strong
> testing team here, and we would en un with pages that are not being
> tracked- Hide quoted text -
>
> - Show quoted text -

Ah, got it! You should set the cookie only once, in your
authentication form (e.g. login.aspx). The default expiration date of
a cookie is the current session. It means this cookie will expire when
the session is ended. Or you can explicitly set the date, for example
+1 year. It could help to track existed customers who has not
authenticated.

You can also use global.asax, e.g. Application_BeginRequest() method
(for all requests) or Application_AuthenticateRequest() (for
authenticated users only).

On May 29, 3:40 pm, Alexey Smirnov <alexey.smir...@gmail.com> wrote:
> On May 29, 10:10 pm,arthernan<arther...@hotmail.com> wrote:
>
>
>
>
>
> > On May 29, 3:05 pm, Alexey Smirnov <alexey.smir...@gmail.com> wrote:
>
> > > On May 29, 9:56 pm,arthernan<arther...@hotmail.com> wrote:
>
> > > > On May 29, 1:37 pm, Alexey Smirnov <alexey.smir...@gmail.com> wrote:
>
> > > > > On May 29, 6:50 pm,arthernan<arther...@hotmail.com> wrote:
>
> > > > > > OK, let's assume I do, Should I code it like MyLib.MySession(Me,
> > > > > > "CustomerID") and avoid dealing with inheritance. Or should I code it
> > > > > > MySession("CustomerID")- Hide quoted text -
>
> > > > > I think all what you need is to set a cookie
>
> > > > > Response.Cookies["CustomerID"].Value = Session["CustomerID"];
>
> > > > > Note, you will need a reporting tool which could read that values from
> > > > > the IIS log.
>
> > > > It's just easy to miss. I'd like something more foolproof.
>
> > > What would make it more foolproof?
>
> > > When you save a cookie, the cookies will be logged in IIS log among to
> > > other data, making them available together to be used in your
> > > reporting. If you gonna save that CustomerID somewhere else, like in a
> > > database, you will have a problem to link the ID and IIS log.- Hide quoted text -
>
> > OK, I did not make mysefl clear. The line:
>
> > Response.Cookies["CustomerID"].Value = Session["CustomerID"];
>
> > Could be easily missed during programming. We don't have a strong
> > testing team here, and we would en un with pages that are not being
> > tracked- Hide quoted text -
>
> > - Show quoted text -
>
> Ah, got it! You should set the cookie only once, in your
> authentication form (e.g. login.aspx). The default expiration date of
> a cookie is the current session. It means this cookie will expire when
> the session is ended. Or you can explicitly set the date, for example
> +1 year. It could help to track existed customers who has not
> authenticated.

I thought we had multiple points of entry, and that they could
increase. But it's not the case.

I think, I complicated myself on this one.


> You can also use global.asax, e.g. Application_BeginRequest() method
> (for all requests) or Application_AuthenticateRequest() (for
> authenticated users only).- Hide quoted text -

This is a good suggestion too. I'll keep it in mind.

Thanks