The Session object

M

Mondeo

Centurion
Joined
Nov 10, 2006
Messages
128
Location
Sunny Lancashire
I have a simple site which displays a list of members, users select a member and get redirected to a page about that member like this.

members.aspx?member=109

Now my client isnt comfortable with the member ID on the query string as competitors can simply increment the member ID and obtain a list of all the members.

So I though about using the session to store the member ID, then retrieve it on the next page and get the details.

I havent used the session at all before and have a couple of questions.

1. Firstly will it work in all browsers
2. Does it rely on cookies, and will it stop working if the user has cookies turned off for security.

Thanks
 
AFAIK.

1. Yes it will work in all browsers.
2. You can set the option whether to use cookies or not. Hence if you use cookies then the client browser should enable cookies.
 
Do you need sessions

Maybe I've misunderstood your situation, but I can't see how sessions would help here. The user must have some way of specifying which member's details they wish to view, and whatever that is, the competitor could abuse it. Sure, it would make it slightly more cumbersome for the competitor to iterate through members, but not impossible. Encrypting the member ID in the querystring would be more robust and user-friendly (since URLs can be copied and pasted).

If you want to only allow logged in (known) users to view member details, then you could use one or more location blocks within the web.config file (shown below), or HttpContext.Current.User.Identity.IsAuthenticated within code to restrict access.

Code: 
<configuration>

  <!-- ...
       rest of config file
       ...
  -->

  <location path="~/members.aspx">
    <system.web>
      <authorization>
        <deny users="?"/> <!-- Deny anonymous users -->
        <allow users="*"/> <!-- Allow authenticated users -->
      </authorization>
    </system.web>
  </location>
</configuration>
 
The way it works is users put in thier postcode and then the site shows a results page with the closest 5. I know what you mean, even using sessions someone could do a script to loop through a postcode DB and get all the members eventually.

But it would take a programmer to do it really, at least this would stop the casual attempts. The other way I thought was along your lines as well as the numeric primary key for the members I could generate an alternative alphanumeric key like a7hg5ryt9 which I could use on the query string.

What do you think? Membership is out of the question unfortunately as its a public site.
 
ID encoding

As you've described it, the sessions approach seems like it would work well.

Personally, I would go with the extra alphanumeric ID, or devise a system where an ID number can be converted to and from a unique, non-sequential alphanumeric token. In a similar project, I wrote two methods, EncodeMemberID and DecodeMemberID to ensure that all client-side IDs were in this encoded format. The design of the encoding/decoding routine involved some bit/byte manipulation, hex encoding and a substitution dictionary (basically a cipher), with validation characters to prevent ID 'guessing'.

The reason I used this approach is that in this particular project the "member" pages were linked to from almost all other pages, and it was important that we had copy-and-paste-able URLs so that people could access them directly and share the URLs with others.
 
If you're using 2.0 why don't you just post back to the referring page that way it could have access to the previous page variables? I wouldn't advise tying up session memory with specific page variables like this. Session is designed more for things that are global across the site for that user, such as there formal name ('John Doe' instead of their login of jdoe) or preferences. An old fashioned way of doing this (1.1 compliant) would be to post back to the page and instead of using Response.Redirect, use Server.Transfer and then you could use public properities of the original page that could be accessed by the new page through context (cast).
 
Is there meant to be a restriction on who can access which member's details or can any member access any other member's details?

If there is some form of authorisation required then MrPauls' suggestion of implementing some form of security model is a must.

If on the other hand anyone can access any member's details whatever you do will still require some form of information to be sent from the browser to the server and as such will be susceptible to exploits.
 
PlausiblyDamp said:
Is there meant to be a restriction on who can access which member's details or can any member access any other member's details?
Click to expand...

No restrictions, the member search facility is public. Its not me that has a problem with it but my client is concerned that her competitors can increment the memberID and one by one get all the members to approach.

She's worried about this because this is exactly what she did on someone elses site to get most of her members. :eek:

I think i'm going to take MrPauls earlier suggestion and have a secondary unique key in the members table, like igjg76dhdy that is meaningless and cant be incremented.
 
Back
Top