What has v11 done with Session variables?

[CALocklin]

Re: What has v11 done with Session variables?

OK, I'm convinced NONE of my session variables are working as session variables in v11 even though they still work perfectly in v9. I've tried every combination of DIM including DIM GLOBAL, plain old DIM, DIM SHARED, no DIM at all (like my original pages), and even DIM LOCAL and nothing makes the session variables work - in v11. But they still work fine in v9 with no changes to the A5W pages.

A couple test pages are attached if you want to try them on your own v11 server. These are very simple, hard coded pages that should work on any A5 WAS server. No database is required - just stick the pages on your server and open session_test1.a5w.

NOTE 1: The session_test1.a5w page calls session_test2.a5w but session_test2.a5w calls itself. I tested with a "session_test3.a5w" and the results were the same as having the second page call itself.

NOTE 2: There are 2 "session" variables created. One was created outside of (before) the <form></form> section and the other is created inside the form. They are displayed in an <input> box in session_test1.a5w so you can change the text to anything you want.

NOTE 3: If checking the code, don't get confused by the <table> in the a5w page. The only reason the <table> exists is because the original pages that were stripped down to make these had tables in them - I was just too lazy to remove the tables when testing.

NOTE 4: I added some traps to determine when a variable was "lost" and created appropriate messages. Without the traps the page would just error out.

Can anyone figure out why the "session" variables in these pages don't act like session variables on a v11 server?

Here's how they work on a v9 server.

And here's the result after clicking the initial submit button in v11:
session_result1.png

And here's the result after clicking the second submit button in v11:
session_result2.png

[kkfin]

Re: What has v11 done with Session variables?

First if you add in both files code
?a5w_info()
it is easier to follow what actually is happening.

When session_testi1.a5w loads to the screen session.outside is created as a session variable.
Then you try to create session variable in post body(when you submit form) but session variables cannot created from POST body.
This means that session variable session.inside is not created when session_test2.a5w loads.

When session_test2 loads session.outside session variable still exists (everything ok) but session.inside does not exists and so you have this code in file session_test2
..
IF .not. eval_valid( "session.inside_form" )
session.inside_form = "Session Variable lost"
...

This is where you in fact create your second session variable session.inside_form. It will have value :"Session Variable lost" You can see this if you submit form again.

EDIT: When you post your form session_test1 you create a local variable session.inside_form in POST body which you can see in session_test2 first time. When you submit session_test2 then local variable session.inside_form does not exists anymore when session_test2 reloads and session variable session.inside_form is created

[Steve Wood]

Re: What has v11 done with Session variables?

Cal, what A5 patch are you using? A similar test works properly for me.

[kkfin]

Re: What has v11 done with Session variables?

Cal, what A5 patch are you using? A similar test works properly for me.

What means works properly?

[CALocklin]

Re: What has v11 done with Session variables?

Ken,

I think you're missing something. It was always my opinion (and this is the way it works in WAS for v7, v8, and v9) that once a session variable is created it exists for the duration of the session and can be accessed from any page without setting it again or passing it from one page to another. (see Alpha's Help comment below) It's just "there" the same way a GLOBAL variable is just "there" in every script, form, etc. on the desktop once the global variable has been created. Using "Get" or "Post" doesn't matter because those only affect variables that are passed via the call to the next page. Actual session variables never need to be passed to the next page; they exist as part of the entire session not as part of the page - which is why they are called "session" variables.

In my example, the session.inside_form variable gets passed to page 2 initially because is was inside the <form> section. That's the point of the example - the form variable named "session.inside_form" gets passed initially but it apparently isn't an actual "session" variable because it then goes away. Session variables should never go away unless your code actually removes them.

Here's what Alpha's Help file has to say about session variables:
To create a "session" level variable, simply name it session.varname. It will then be persistent across all page views and can be later referenced as session.varname in subsequent pages.

The way I see it, your statement:
"When session_testi1.a5w loads to the screen session.outside is created as a session variable."

should really be:
When session_testi1.a5w loads to the screen a variable called session.outside is created but it really isn't a true session variable because it doesn't exist anymore when you call the next page. True, it is defined with "session." as the pointer but for some reason it doesn't actually get set up as a session variable.

Later you say:
This is where you in fact create your second session variable session.inside_form.

But that isn't true. Both variables - session.inside_form and session.outside_form - were created in the first page. Once created they should not have to be re-created or passed to another page. However, I do have a routine in the second page that checks to see if the variable exists (IF .not. eval_valid...). If it doesn't exist then a new variable with the same name is created but this one has an 'error' message to point out that [what was supposed to be] the session variable disappeared.

OK Now that I've written all that....

In the middle of writing the above, I decided to try the example in Alpha's Help file (link above) and discovered more details about what happens - in the v11 WAS - when defining session variables....

The problem seems to be a complex issue having something to do with <input> boxes and <forms>....

"Session" variables defined with xbasic:

When a session variable is defined in an xbasic section using something as simple as session.myvar = "Fred" either inside or outside a <form> section you can open that page to initialize the session variable then just type a URL in the browser's address line to open another page referencing that same session variable and it works. It also works if the second page is opened with an <a href> command. However, NO "session" variable created with xbasic inside or outside the form will exist if the second page is opened by submitting a form. However, if a variable named "session.<name>" is included in an <input> box, it will be transmitted to the called page but only as a local variable - not a session variable. In addition, if a session variable is defined in xbasic then included in an <input> box, only the original definition will exist as a session variable. You can change the <input> box all you want but (a) only the original definition will exist in the session variable (and only if typing the name of the second page in the address bar or using <a href>) and (b) the <input> box value will only be transmitted if the form is submitted and even then it will only be as a local variable.

"Session" variables defined in an <input> box:

No actual "session" variable will exist if the second page is called by submitting a <form>. A "session" variable defined (or previously defined in xbasic then used) in an <input> box will be transmitted to the second page but only as a local variable - NOT as a session variable.

BUT WAIT, it gets worse....

If you called the second page by submitting a <form>, then, as mentioned before, the session variables won't exist. BUT if you then call that second page again, the session variables will magically appear!

It's enough to drive a developer crazy!!!

And I just noticed that the initial call to the second page when submitting the <form> only shows the page name. However, when I resubmit the second page from itself, the address bar includes a session ID like this:
http://localhost:81/htdocs/inside/Session_test2.a5w?A5WSessionId=bb158b80658e4a80abb1087bf259b672

Methinks Alpha has an issue.

My latest test pages are attached if anyone wants to try them.

[kkfin]

Re: What has v11 done with Session variables?

Ken,


In my example, the session.inside_form variable gets passed to page 2 initially because is was inside the <form> section. That's the point of the example - the form variable named "session.inside_form" gets passed initially but it apparently isn't an actual "session" variable because it then goes away. Session variables should never go away unless your code actually removes them.

Methinks Alpha has an issue.

Your code works just as expected and there is no issue at all. You can not create session variable posting a form. That is the point. Check here under header session variables.

In your session_test1 you create just one session variable the outside one. You try to create also inside session variable but that is not a session variable at all. Alpha accepts your naming (using session) but does not create session variable.

[Steve Wood]

Re: What has v11 done with Session variables?

Ken,

Sorry, I was incomplete in my post. Should have said "a similar test to confirm session vars were working properly". You are totally correct thar session vars cannot be set via post or get (a form). That started in v11.

[Steve Wood]

Re: What has v11 done with Session variables?

Cal,

If you want to set a session var when an HTML form button is clicked, use this general method:

<%a5
delete session.myvar ' to ensure it is removed prior to start
if variable_exists("submitbutton")
session.myvar = "myvalue"
end if

if variable_exists("session.myvar")
?"here is the var: " + session.myvar
else
?"session var not set yet"
end if
%>

<form method=POST>
<input type="submit" name="submitbutton" value="Submit">
</form>

Of course, this is really setting the session var 'outside of the form', but as Ken says, you cannot set a session variable via POST or GET (form). This alternate method checks to see that 'submitbutton' exists, meaning they clicked the submit button (your submitt button name may differ.).

The ability to set session variables in POST or GET was removed in V11 as a security enhancement. So you can no longer set a session var in a URL like "mypage.a5w?session.name=steve"

[CALocklin]

Re: What has v11 done with Session variables?

Steve - yes, that would work if all I needed to do was to set a variable (or variables) inside the form. The problem is that I also have to set about 15 session variables outside of <input> boxes (based on customer info) then click the Submit button. When I do that, all the session variables that were set outside the <input> boxes "disappear" until I submit the second page - then they reappear! To see this phenomenon:

- open session_test1a.a5w and type something different in the "inside the form" input box - just "xxxx" will work fine.
- click the Submit button on this page and you will see that the session variables created outside of an <input> box (session.outside_form and session.calsvar) are lost when the 2nd page opens but the text you typed in the <input> box is displayed.
- click the Submit button on page 2 (which just calls page 2 again) and the session variables all reappear - including the original <input> box text that was there before you changed it. (This is the issue that could be resolved with your code but what about the other session variables!?)

Repeat the above using an earlier version of the WAS and the session variables will remain session variables at all times. (This includes the one that was changed in the <input> box. It keeps the value you typed which means there's no "fancy footwork" required to set/reset a session variable.)

Oh, and it says I'm using the latest patch - 3044-4041

Unless someone comes up with another solution, the way I see it there are three possibilities now: (1) Figure out some work-around to make ALL the session variables usable and re-write all my pages to use the workaround, (2) report this as a bug to Alpha and hope they will fix it so session variables will "stick" like they did in all previous versions. (And if they don't fix it in v11, my customer will have wasted his money purchasing v11), or (3) give up on session variables and just pass all variables as local variables from page to page to page.

[CALocklin]

Re: What has v11 done with Session variables?

Your code works just as expected and there is no issue at all. You can not create session variable posting a form. That is the point. Check here under header session variables.

In your session_test1 you create just one session variable the outside one. You try to create also inside session variable but that is not a session variable at all. Alpha accepts your naming (using session) but does not create session variable.

I completely disagree with your first sentence and I had to read that link about 5 times before finally agreeing with your second sentence (although I think it's a stupid change - see below) BUT that doesn't answer the issue with the other session variables that were created completely outside of <input> boxes or even outside the <form> and that seem to disappear upon initial call to the next page.

Why I think it's a stupid change....

If a session variable cannot be edited in an <input> box, then all session variables should only be set once per session and never allowed to be changed. This might be fine for setting something like customer defaults but doesn't work well at all for setting selection criteria that might change. Since an <input> box can't work with a session variable anymore, changing a session variable in the middle of the app becomes a complex issue. Consider this situation: The user needs to make some selection choices to filter some output for a report. These choices require an <input> box so they can be selected by the user (duh!). There are 10 choices the user has to make AND the user might go back and forth between the "selection" and "results" pages varying one or two of his choices each time until he gets the results he wants or just to get different results. If those 10 choices are in actual session variables then the previous selections will still be there every time the user comes back to the "selection" page. (This is the way my app is set up right now.) BUT, now that Alpha won't see anything in an <input> box as a session variable, the user will either have to keep track of his original selections and start all over OR I will have to design the app so ALL user input will be in local variables and passed back and forth from page to page to page to page - a daunting task but maybe one that has been forced upon us. If this is the way it will be, I will refuse to support any v11 WAS apps.

EDIT:

Upon further thought, it would be workable (but a pain in the 'whatever') if only those values in the <input> boxes were an issue. The really big issue is that the session variables created outside the <input> boxes disappear when the Submit button is pushed to access the next page.

EDIT 2:

I'm about to go crazy with this thing. I just went back and tried the last test again and this time none of my session variables ever appear. They're just gone! Further checking proved that my original "they disappear then re-appear" statement was a result of multiple tests without starting a new session. If I create the session variables on a page that does not contain a <form> section then run tests on pages with a <form> section, the session variables will disappear and re-appear. If I start a brand new session and every page has a <form> section, any "session" variables disappear when opening a new page and they are just plain gone. It appears that there is no point in using session variables at all if there is a <form> on any of your pages.

Yes, you can do something like "session.myvar = myvar" to temporarily set what appears to be a session variable. But if that page also uses a <form> then the next page won't be able to see your "session" variable.

Right now it appears that the only solution is, "You can use a <form> or you can use session variables but you can't use both."

[kkfin]

Re: What has v11 done with Session variables?

- open session_test1a.a5w and type something different in the "inside the form" input box - just "xxxx" will work fine.
- click the Submit button on this page and you will see that the session variables created outside of an <input> box (session.outside_form and session.calsvar) are lost when the 2nd page opens but the text you typed in the <input> box is displayed.
- click the Submit button on page 2 (which just calls page 2 again) and the session variables all reappear - including the original <input> box text that was there before you changed it. (This is the issue that could be resolved with your code but what about the other session variables!?)

You can not not create session variables POSTING them. When you type in session_test1.a5w something different in the "inside the form" like "xxxx" in input box you are trying to do something that is not allowed in version 11. BUT in real life you are in fact creating request variable and using false naming: session. + variable name. Session in variable name is reserved for session variables not for request variables. You can easily see this if you put in your session_test2.page this code: ? request.body . There you can see your variable.

[Steve Wood]

Re: What has v11 done with Session variables?

Cal,

All of your form input values become page variables when you submit the form. So if you have an Input field named "client_name", then upon submit whatever they typed in that field will be in a page variable named client_name. I've used this method for years. Here is a revised example from my last post:

<%a5
delete session.myvar ' to ensure it is removed prior to start
if variable_exists("submitbutton")
session.myvar = "myvalue"
session.client_name = client_name
end if

if variable_exists("session.myvar")
?"here is the var: " + session.myvar
?"Client Name is: "+ session.client_name
else
?"session var not set yet"
end if
%>

<form action=test2.a5w method=POST>
<input type="text" name="client_name">
<input type="submit" name="submitbutton" value="Submit">
</form>

Note - this is assuming you are using a normal HTML Form on an A5W page, or the legacy A5 dialog. It works differently in the new V11 Dialog2 because it uses Ajax. The old dialog is a simple HTML form in disguise.

[CALocklin]

Re: What has v11 done with Session variables?

So what do you do if you want to get some client info and set it to session variables? If I do this:

tp = table.open("Client")
tp.index_set ( <as needed> )
tp.fetch_find( <whatever> )
session.client_number = tp.client_nof
session.client_fullname = trim( tp.first_namf ) + " " + trim( tp.last_namef )
tp.close()

That SHOULD set some session variables. And this does not need to be part of a form. At least it shouldn't need to be part of a form. However, this method in v11 results in no actual session variables at all when I click a Submit button for a form to call the next page - whether the called page is the current page or a different page.

If I have to add your "IF variable_exists()" code to the subsequent page for every "session" variable every time I submit a page, why am I even bothering to use session variables. All my tests so far indicate that, in v11 only, ALL session variables disappear when there is a form on the page and you press the submit button.

In fact, if the variables are set as I described above and I want them to be transmitted to the next page when the Submit button is pushed, I have to use a name without "session." and put them in a hidden input box so they will be transmitted:

tp = table.open("Client")
tp.index_set ( <as needed> )
tp.fetch_find( <whatever> )
client_number = tp.client_nof
client_fullname = trim( tp.first_namf ) + " " + trim( tp.last_namef )
tp.close()
....
<form ...>
<input type="hidden" name="client_number" value="<%A5?client_number>" )

Then I convert them to a "session" variable in the next page but the next page also has a <form> so I again have to rename them and put them in hidden input boxes so I can transmit them to the next page - and on and on and on. So what's the point of a session variable? I'm basically finding that every time I click a Submit button all session variables disappear. If that's not the case, please show me an example so I can figure out what I'm doing wrong.

And, yes, I'm using plain HTML with xbasic interspersed. There are no web components at all.

[CALocklin]

Re: What has v11 done with Session variables?

All of your form input values become page variables when you submit the form.

This part I understand. [EDIT - Comment removed. I'm not sure but maybe it was this way all along. The rest is still true.] But that's beside the point.

The bigger problem is that when I try to set a simple session variable using a plain:
session.myvar = "something"
anywhere on a page that uses a <form>, the so call "session" variable disappears when the Submit button is pushed.

If a session variable won't stick from one page to the next, what's the point of a session variable? A lot of my pages use forms (and I'm guessing a lot of other people's pages use forms) so session variables in v11 seem to be completely useless.

[kkfin]

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? A lot of my pages use forms (and I'm guessing a lot of other people's pages use forms) so session variables in v11 seem to be completely useless.

The problem here is that request variable (sorry for the term but easy understand) overwrites session variables value if the request variable has same name as session variable as you noted earlier. This is very very bad behavior.

Imagine you are showing security.a5w page using session.quid (or something silmilar) as a filter.
But because request variable with same name overwrites..... I don't think I have to continue this example.