0

I've added bits of debug code in an attempt to figure out what is going on with my Session variable, and it appears that it is always empty.

Could someone tell me what I am doing wrong?

This is probably some noobie mistake, because I don't do much web development.

private const string PASSWORD = "PASSWORD";

protected void Page_Load(object sender, EventArgs e) {
  if (String.IsNullOrEmpty(password)) {
    lblMessage.Text = !IsPostBack ? "Not a PostBack!" : "A PostBack.";
  } else {
    ShowData(IsPostBack);
  }
}

private string password {
  get { return Session[PASSWORD] as string; }
  set { Session[PASSWORD] = value; }
}

protected void Password_Click(object sender, EventArgs e) {
  string val = txtPassword.Text.Trim();
  if (val == ConfigurationManager.ConnectionStrings[PASSWORD].ConnectionString) {
    password = val;
    txtPassword.Text = null;
  } else {
    Response.Redirect(val);
  }
}

private void ShowData(bool postType) {
  // I would display my data here if it ever got to this point!
}

EDIT: When the Password_Click event fires, all I ever see is "Not a PostBack!" or "A PostBack." So, my Session variable must not be getting set.

12
  • does your site run on just one server, or is it hosted on multiple servers behind some sort of load balancer? Commented May 9, 2013 at 21:51
  • It is hosted by GoDaddy. Otherwise, I don't know how to tell. Commented May 9, 2013 at 21:53
  • 1
    Unless you have specifically disabled sessionstate (which I don't think you did), your code looks OK. The only thing I can think of is that your method Password_Clickdoesn't get called. Can you put a breakpoint there and see whether the variable actually gets set. If not show us the ASP.NET markup so we can see why it's not firing the event Commented May 9, 2013 at 21:58
  • @Kenneth if sessions were disabled he would be getting an exception. Commented May 9, 2013 at 21:59
  • Yes you're right, that's why I figured he didn't because he didn't mention any exceptions. However his code should work if everything is set up all right. Commented May 9, 2013 at 22:01

3 Answers 3

1

Unless you have specifically disabled sessionstate (which I don't think you did), your code looks OK.

The only thing I can think of is that your method Password_Click doesn't get called.

Please put a breakpoint there and see whether the variable actually gets set. If not show us the ASP.NET markup so we can see why it's not firing the event

Sign up to request clarification or add additional context in comments.

Comments

1

Looking at your code, the only "issue" I see which can create this behaviour is this line:

Response.Redirect(val);

I would say that your are getting a redirect, because otherwise your code seems right to me.

2 Comments

Not a redirect. Kenneth was right. I had some dumb noobie error. I never wired up the Password_Click method. OMG.
Well this kind of thing happens to us all :)
1

In this scenario the only way Session[PASSWORD] (effectively Session["PASSWORD"]) gets set is if there is an entry in your web.config:

<configuration>
    <connectionStrings>
        <add name="PASSWORD" connectionString="xxx" providerName="<Some Provider>" />
    </connectionStrings>
</configuration>

And you type a string in txtPassword control that matches the string in connectionString attribute of the PASSWORD entry in the section of your web.config

2 Comments

Actually, when Password_Click is fired, the string in txtPassword.Text is assigned to Session[PASSWORD] - which can be anything! Even StackOverflow. I simply reused an existing value in my code when writing the connection string in the Web.config file, so that line would look like <add name="PASSWORD" connectionString="StackOverflow">. I'm sure there are other/preferred ways to store the password in a config file, but I know how to use the connection string! :)
Well that was the point I was getting at :) - I assumed the connection string was just for example purposes - but you should look into AppSettings - same idea, but a more appropriate place than ConnectionsStrings for what your doing here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.