What has v11 done with Session variables?

[Steve Wood]

Re: What has v11 done with Session variables?

If a session variable won't stick from one page to the next, what's the point of a session variable?

That statement is of course false, otherwise every one of our applications would be failing to work. Its possible that your method of setting the session variable is failing, but that means you have to change how you set them. I am away from my office or I would prepare some additional examples, but what I (and Ken) have already provided is accurate.

[kkfin]

Re: What has v11 done with Session variables?

That statement is of course false, otherwise every one of our applications would be failing to work. them.

The problem here is that you can overwrite the session variable that alreay exists with post or get creating variable that has same name as session variable.

[Steve Wood]

Re: What has v11 done with Session variables?

Ken,

Yes that makes sense. If you generate a page variable named "name" you will have a local variable named "name", and that is no different than generating a page variable named "session.name" will create a local variable named "session.name". It USED to be true that the second example would create a persistent session variable that could be reused throughout the application. But that is no longer true.

I think you already said that below, but I am watching the 49er game - half time and they are behind right now. EDIT: Well that turned out well.

[CALocklin]

Re: What has v11 done with Session variables? SOLUTION

SOLUTION (I hope!)

I think I finally figured it out.

To make it simple, I had some <input> boxes inside the <form> section that were causing the whole problem. However, these were "hidden" input boxes that were only used by javascript to set values for screen width and screen height. (JavaScript needed a control with an ID in order to set the values. Hence the hidden input boxes.) These were not input boxes that the user could see or use. They didn't really need to be inside the form and I have no idea why I decide to put them there in the first place - that was too many years ago.

As mentioned previously, this method worked fine in v10 and earlier. However, in v11 it does something really weird. It doesn't just transmit those variables as local variables - it wipes out ALL other session variables that were properly set outside the <form> section!

And my test pages were confusing because I was trying various things not knowing what the issue was. The weird results didn't make sense so I kept trying new things to try to figure out exactly what was happening. And one of the weird things was that the session variables would sometimes "reappear" on a second attempt - that one I still don't understand and I won't even try to understand it now that I know how to avoid the original problem. I also think some of the confusion was the result of not always starting with a clean session but I'm not sure.

Anyway, I finally realized that whenever there was an <input> box inside the <form> that had any variable starting with 'session' - whether used anywhere else or not - ALL the session variables on the form would disappear when the form was submitted. Not just the one(s) in the <input> box(es) - ALL of them.

The fact that the <input> box in the <form> was affecting other session variables made it much harder to figure out what was going on.

At times I had solutions that seemed to work but I didn't know why. Since I have a lot of other pages with similar issues (session variables and <input> boxes), I really wanted to understand what was happening so I could avoid the problem in the future.

Thanks for bearing with me and giving me ideas and links. I'm sure it would have taken me a lot longer to figure it out completely on my own.
Cal

[Steve Wood]

Re: What has v11 done with Session variables?

I'd still like an example of your failing page to test so to write a general statment and solution or guide.

[Peter.Greulich]

Re: What has v11 done with Session variables?

Cal,

I feel your pain But I learned something from this thread so your pain was worth it!

Have you taken a look at the new dialog2? But I digress.

[CALocklin]

Re: What has v11 done with Session variables?

I'd still like an example of your failing page to test so to write a general statment and solution or guide.

Files attached.

Run the session_does_work.a5w and everything should work correctly. I included the JavaScript routine I used to set the Session.screen_wd variable. This page also contains a brief (that's all it really takes) explanation of what to do and not do when creating session variables in v11. (It may have been the more "correct" method in v10 and earlier but those versions didn't mess things up as badly if your code wasn't completely "correct".)

Run the session_does_not_work.a5w to see what happens if you try to use an Input box that has a name beginning with "session.". In order to "maximize your enjoyment" of this one, be sure to check the results then click the "Resubmit this page" button and check the results again.

(You can also run the session_does_NOT_work.a5w in v10 or earlier to see the difference.)

Disclaimer: Sometimes I hate computers - I had varying results as I was creating these pages so I won't guarantee they will work as I expect. These pages gave me different results at different times during development but after shutting down both A5 and Windows Explorer and having dinner and watching some TV before restarting them, they seem to be working as expected now. (I saw your request for the failing page right after deleting all my original test files. However, recreating them did clarify some things for me.)

Steve, my actual page has some customer info on it and I don't want to post that here. PM me if you still want a copy but don't expect to learn a lot more than "don't use a 'session.' name in your <input> box."

[Steve Wood]

Re: What has v11 done with Session variables?

After testing your 'does_not_work' page, this was said earlier, but if you ONLY ensure you do not POST an input field named session.something, then all session variables created previous in the system (using xbasic) anywhere, including the page with the form, are remain valid.

In my test I only renamed the Input field that was INSIDE the Form to not start with "session.", as below:

<input type="text" name="xxxSessionxxx.inside_form_input" value="Created in Input box inside the form." style="width:40EX" >

The input field OUTSIDE of the form only affects the page that it is on, creating a local variable, does not affect session vars on any subsequent pages.

So, as I think Ken said, you cannot create a session variable in a POST or GET (Form input fields).

And this is exactly what it says in the Server Programming Changes for V11 in the Help Doc:

Session Variables cannot be created directly from a request query string or POST body. This negates the need to use "protected" session variables, as all session variables now effectively "protected". In order to create a session variable, you must execute A5W code to read the request variable and create or set the session variable. A request for a URL such as http://localhost/index.a5w?session.name=John will not create a session variable session.name, but will instead create a request variable which may be accessed as Request.Variables.session.name during the lifetime of that request only.

[Steve Wood]

Re: What has v11 done with Session variables?

By the way, I hope you are charging your client for this change they decided to make on their own. I put it in writing that I make no guarantees the app will work perfect on a future release/patch or Alpha, or Windows, or IE, etc. As I said in some other post, a client had me going all day trying to figure out a "sudden new bug in MY application", but failed to tell me, until I figured it out, that he upgraded to IE10 that same morning.

[CALocklin]

Re: What has v11 done with Session variables?

You're correct about how it should be done and about what was wrong. BUT, I think you're still missing the point of my problem. You guys only seem to be thinking about the session variable in the <input> box but that didn't seem to be the initial problem. (It was but it didn't look that way.) The initial problem seemed to be what happening to all the other session variables that were correctly created in xbasic - in v11 they just disappeared and that caused the second page to fail. NOW I know it was because there was a "session" variable (which we now know wasn't really a session variable) in the <input> box but in v10 all the other session variables remained valid session variables even when there was [incorrectly] a "session" variable in the <input> box. Consequently, it looked like v11 was losing all my session variables. (And it was - and v10 didn't do that.)

That was what caused all the confusion trying to fix this. True, I shouldn't have used the input box with a session variable in it in the first place but it caused some really, really weird results in v11 that caused me to look somewhere other than where the actual problem was. In v11, correctly created session variables (actually you could say ALL session variables) were disappearing when the next page was called. Consequently, my initial problem was focused on fixing all the other session variables that were created correctly. After all, they were the ones that seemed to be causing my problem. Now I know that the ones that were the root cause of the problem were the ones in the <input> boxes but those particular variables were seldom used and did not even affect the next page - which was the one that generated the error. The second page was failing because the correctly created session variables were disappearing. Consequently, the "session" variables in the <input> boxes received far less of my debugging focus initially than the ones that were actually causing a problem on my second page. I wasn't expecting a problem with Variable_A to cause a problem with Variable_X since they were both used for completely different purposes.

My initial problem wasn't "the session variables in the input box are disappearing." My initial problem was, "ALL my session variables are disappearing when I run this in v11!" In fact, my first post states: "Testing reveals that all session variables set in the index page disappear when I click the Submit button but all session variables created on the current page remain valid." And when a page doesn't work, you tend to focus on the specific variables that seem to be causing the failure on that page - not on some other minor variable that isn't even used on that page.

As for charging the customer, I probably won't charge him for all the time I spent on it but I will charge him.

NOTE: For those reading this but not familiar, when I refer to "using a session variable in an input box" I'm referring to setting the name to that of a session variable. Something like this:
<input type="text" name="session.MyVar" value="Fred" >
NEVER do that but it's perfectly acceptable to use a session variable to set a value in the input box:
<input type="text" name="SomeVar" value="<%a5 ? session.MyVar %>" >
Just don't put "session." in front of the name! That will cause v11 to remove all your session variables when the next page is called. (But they do come back later - if you can get that far.)

Anyway, thanks again for all the help on this. At least we now know what to look for if all our session variable seem to disappear.

EDIT:

After testing your 'does_not_work' page, this was said earlier, but if you ONLY ensure you do not POST an input field named session.something, then all session variables created previous in the system (using xbasic) anywhere, including the page with the form, are remain valid.

Yes, this is another way of saying "Never name an <input> control as a session variable." However, it still seems rather odd to me that setting one variable incorrectly should cause other variables to disappear - and only temporarily at that. Yes, I understand that they both start with "session" but one should be a local variable and the other should be a "global" variable. Obviously Alpha isn't handling them in such a way as to make this distinction. Presumably that's because of their change to consider all "session" variables as global and the way it was implemented causes the session prefix in the input box/control to do a good job of messing things up. (I know, I wouldn't have these problems if I'd just do it right the first time. But, come on, I make one mistake every few months and you're gonna hold it againt me!? And, yes - for those who might miss it - I'm being facetious.)

[Steve Wood]

Re: What has v11 done with Session variables?

Your quickest solution is to follow this model. It accepts the input or hidden, and puts them in session vars before going to the next page, if any:

<%a5
if variable_exists("submitbutton")
'dim as necessary. (Although all session variables must be character; not forced now but may be forced later on. But that is for another long thread later on.)
session.client_name = client_name
session.client_code = client_code
session.client_number = client_number
end if

<form action=anypage.a5w method=POST/GET>
<input type="text" name="client_name">
<input type="hidden" name="client_code" value="12345">
<input type="hidden" name="client_number" value="<%A5?client_number %>">
<input type="submit" name="submitbutton" value="Submit">
</form>

[Lenny Forziati]

Re: What has v11 done with Session variables?

The entire problem described in this thread is a result of naming the FORM variables with session. as part of the name. This was in fact previously an acceptable programming technique, but also lead to potential security exploits. Version 11 introduced a very important change whereby any variables from a query string or POST body could not create or update any session variables at all.

However, Cal has been further frustrated by what is essentially a silent failure - when the POST or query string contained a variable named session.something, it would create a locally scoped session pointer which masked the global Session object. Once the global object was masked, any Xbasic code working with what should have been session variables would have instead referenced the local pointer with no warning.

Beginning with build 3200, this will no longer fail silently. Instead, attempting to create or update a session variable from either POST or query string data will result in an error. Code using the older technique will still need to be updated, but the problem should immediately be clear instead of having to wonder why things are not working as expected.

[CALocklin]

Re: What has v11 done with Session variables?

Thanks Lenny!

And just so you don't think I'm the only one that did this and you're fixing it just for me (which shouldn't be necessary now that I know the issue), I already found another developer that has done the same thing. He just hasn't used the V11 WAS yet.

[RichCPT]

Re: What has v11 done with Session variables?

I'd still like an example of your failing page to test so to write a general statment and solution or guide.

Steve, a solution guide to using Session variables would be great. I have begged for such a thing for quite some time for version 11. Perhaps it exists and I just don't have the right alpha support subscription to get it? There have been changes to session vars throughout version 11, so the minimum build # of V11 would have to be specified that works for the tutorial.

I'd like to see a tutorial that works under both Working Preview (WP) mode and WAS mode. As I'm sure you know, in WP the session vars can stick around until you exit A5. That makes it quite confusing when you get code working just right, but the next time you open A5 it does not work. Then there is the xbasic event handler issue about using "e.SESSION.your_var" or just "SESSION.your_var" without the "e" prefix which occured in V11. WP mode liked it one way, but WAS liked it another! Do they both like it the same way now, without the "e." prefix? In Javascript for components there is the "{}.getSessionVariable()" method to discuss. And, I'd really like to know, am I going to get into trouble later with my Tabbed UI application that uses the builder's "Override Settings" option to set session variables when grids call other grids or dialogs? I worry that the user might open two instances of the same component and a conflict in the session variable values might occur.