Issue with threading?

[darrel]

This is a long-overdue item on my punch list that I haven't had much time to
address in the past. I'm trying to get it off my plate this week. ;o)

We have a home-grown CMS that works pretty well. One issue we have is that
whenever a page is saved in the CMS, we grab the info about the user that is
saving the page and save it along with the page (so we can track who has
changed what).

This works most of the time.

SOMEtimes, however, it grabs the information from another user that is
logged in. It seems as if my threads are crossing. I'm trying to figure out
what I've failed to do correctly in my code.

To grab the userinfo, we call our class from one of our pages:

SecureUsers.su_ strUser

The secureusers class:

=============== ==============

Public Class SecureUsers
Public Shared su_strUser As String
...
Private Sub Page_Init(ByVal sender As System.Object, ByVal e As
System.EventArg s) Handles MyBase.Init
InitializeCompo nent()
su_strUser =
Server.HtmlEnco de(Request.Cook ies("CMSUser")( "su_strUser "))
End Sub
End Class

=============== ==============

My guess is that it's the 'public shared' declaration for the su_strUser
string and that this is being set GLOBALLY (vs. per session) whenever any
CMS user calls this class. As such, if two people happen to save a page at
the same time, the info crosses.

If that's the case, what should I be using? Is there where I need to use
properties vs. public variables?

-Darrel

--
=============== =============== =============== =============== =====
Win prizes searching google:
http://www.blingo.com/friends?ref=hM...nTqhv-2GE1FNtA

[Aidy]

My guess is that it's the 'public shared' declaration for the su_strUser

string and that this is being set GLOBALLY (vs. per session) whenever any
CMS user calls this class. As such, if two people happen to save a page at
the same time, the info crosses.

If that's the case, what should I be using? Is there where I need to use
properties vs. public variables?

Your guess is correct. The answer depends on the rest of your architecture
really. Is it enough just to removed the shared and make it private?

[darrel]

Your guess is correct. The answer depends on the rest of your

architecture really. Is it enough just to removed the shared and make it
private?

If I make it private or not shared, I can't then access the value from
another page:

SecureUsers.su_ strUser.ToStrin g

-Darrel

[Aidy]

If I make it private or not shared, I can't then access the value from

another page:

If you need to access it in another page then store it in the Session, then
remove from the Session once it has been used.

[darrel]

If you need to access it in another page then store it in the Session,

then remove from the Session once it has been used.

So...it sounds like the issue is that when a person logs into our system,
we're saving their info as a cookie. Instead of saving the info to a cookie,
we should save it to a session? That makes sense.

Now, a new catch: the reason we were saving it as a cookie is that our CMS
is actually 3 separate applications. Yes, less than ideal for many reasons,
and something we hope to resolve down the road. In the interim, is there any
way to share session info between the 3 apps or is that just plain
impossible given that they are three separate apps?

-Darrel

[Aidy]

You can't easily share the Session values, what I'd do is store the info in
a database that all 3 can access.

"darrel" <no*****@nowher e.comwrote in message
news:O%******** *******@TK2MSFT NGP06.phx.gbl.. .

>If you need to access it in another page then store it in the Session,
then remove from the Session once it has been used.

So...it sounds like the issue is that when a person logs into our system,
we're saving their info as a cookie. Instead of saving the info to a
cookie, we should save it to a session? That makes sense.

Now, a new catch: the reason we were saving it as a cookie is that our CMS
is actually 3 separate applications. Yes, less than ideal for many
reasons, and something we hope to resolve down the road. In the interim,
is there any way to share session info between the 3 apps or is that just
plain impossible given that they are three separate apps?

-Darrel

[darrel]

You can't easily share the Session values, what I'd do is store the info

in a database that all 3 can access.

Right...but that kind of takes me back to square one. How does the app know
who the person is to look up their info in the db?

Maybe I should ask a broader question based on our current scenario:

- Our CMS is actually 3 .net application.
- We want people to log into any one of the three and be logged in to the
other 2.

Based on that, what would folks...
a) quick workaround hack solution to get the above working option be?
and
b) more appropriate, more secure option be (even if it includes a
rewrite).

At this point, for 'a', I'm thinking the easiest option is to do what we're
doing, but don't attempt to read the cookie from a class and just read it
directly from whichever page is trying to get the information (as they I can
use non-shared variables). The drawbacks is that this is entirely unsecure
as the login info is all sitting there in a cookie. Thats not too worrisome
for us, as this is an internal app for internal users, but probably not good
practice.

As for 'b', I'm thinking the solution would be to:

- bring the 3 apps together into one app
- store the permission credentials as a session variable

Am I on the right track there? With using the session variable, could I
still read them from a class and not have thread overlap?

-Darrel

[Alvin Bruney [MVP]]

Convert your usersession object into a hash table or namevalue collection.
Use the session id as the key, the value is the user info. To grab
information, you simply use the user's session which is guaranteed unique
and so there is no possibility of data corruption. This is not a
cross-threading issue by the way, it is simple data corruption.

As you know, there is no free cheese. So here is the cache. The size of the
namevalue collection grows unbounded. You will need some sort of cleanup
routine to purge the collection ever so often. In the past, I have used a
global timer to purge the information. How do you know if the information
can be purged? One simple method is to time stamp the last collection
lookup. If it is older than some value, remove it from the collection. I'd
suggest you provider a wrapper class that encapsulates all this logic in one
place.

--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET is coming...
https://www.microsoft.com/MSPress/books/10933.aspx
OWC Black Book www.lulu.com/owc
Professional VSTO 2005 - Wrox/Wiley
"darrel" <no*****@nowher e.comwrote in message
news:%2******** ********@TK2MSF TNGP06.phx.gbl. ..

>You can't easily share the Session values, what I'd do is store the info
in a database that all 3 can access.

Right...but that kind of takes me back to square one. How does the app
know who the person is to look up their info in the db?

Maybe I should ask a broader question based on our current scenario:

- Our CMS is actually 3 .net application.
- We want people to log into any one of the three and be logged in to the
other 2.

Based on that, what would folks...
a) quick workaround hack solution to get the above working option be?
and
b) more appropriate, more secure option be (even if it includes a
rewrite).

At this point, for 'a', I'm thinking the easiest option is to do what
we're doing, but don't attempt to read the cookie from a class and just
read it directly from whichever page is trying to get the information (as
they I can use non-shared variables). The drawbacks is that this is
entirely unsecure as the login info is all sitting there in a cookie.
Thats not too worrisome for us, as this is an internal app for internal
users, but probably not good practice.

As for 'b', I'm thinking the solution would be to:

- bring the 3 apps together into one app
- store the permission credentials as a session variable

Am I on the right track there? With using the session variable, could I
still read them from a class and not have thread overlap?

-Darrel