All session variables protected?

[Pat Bremkamp]

Somewhere in the flood of info about V11, I remember (or maybe I dreamed) that in V11 all session variables are protected. So, we no longer need to designate them as __protected__.

Is that true, or did I just have one too many single malts that night?

[Jeff Blackwell]

Re: All session variables protected?

I read that as well - no comment on your single malt status...

[Lenny Forziati]

Re: All session variables protected?

Yes, it's true. See the Session Variables heading on http://wiki.alphasoftware.com/Applic...hanges+for+V11

Continuing to name them with __protected__ will not hurt anything, except maybe your fingers from the extra typing. The larger issue to be aware of though is in cases where legacy applications may be depending on a Session variable being created from the query string or a form field. These cases now need server-side code to read the GET/POST variable and explicitly create a Session variable.

[Pat Bremkamp]

Re: All session variables protected?

Thanks for the link. While I see having all session variables protected as a benefit, the following is a concern:

Session variables can only be strings (type "C"). While this limitation has always been implied, it has not always been strictly enforced, so legacy code may store other data types as session variables. Going forward, this will not be possible, as it will break session persistence.

Guess I missed that implication! I have created a number of session variables of type N since switching to SQL. So, this means in my V8, V9, and V10 to V 11 conversions, these need to be changed to character?

Is there a way to search for the location of every use of a particular variable?

[Steve Wood]

Re: All session variables protected?

I am programmed to type __protected__; hopefuly I can deprogram. All session vars as character makes it more convenient because you don't have to guess how you dimmed it elsewhere. I am guilty of dimming session vars as numeric since most of my primary keys are numeric. Whenever someone put session var assignment in a URL many of us counceled against that practice, so not suprised to see that it is now prohibited; anyone who did that has to redesign their link.

[Steve Wood]

Re: All session variables protected?

Lenny, question on session vars only being character. Does that mean if an existing application has a session var dimmed as N, that in a future release of V11 that application will break because it will not allow the session var to be dimmed or used as a N? I note that right now (v11:2237-3828) it IS possible to dim a session var as N and that ?typeof(session.myvar) will return N if it has been dimmed as N elsewhere in the system.

Read: Do I need to go back and retrofit any application that uses N dimmed session vars if I intend to keep current on V11 patches?

[Lenny Forziati]

Re: All session variables protected?

Applications running under the V11 Xbasic web server will continue to work.

Applications running under IIS as the web server may need to be modified if you have non-Character types.

[kingcarol]

Re: All session variables protected?

Is there a way to search for the location of every use of a particular variable?

Pat, your question made me curious, so I tried using Edit on top toolbar in Web Projects Control Panel, then Search In All Web Project Files. I typed in session. as my search and it looks like it is finding everywhere that I have used a session variable. What's nice about that search feature is that it shows where it is located and the whole string that the session. was included in.

Lenny... now I'm all alarmed.. We do not use Alpha's security for several reasons that have to do with our multi tenant structure. I use a numerical session variable to establish a user's level of permission, and have used that extensively throughout my application. I check to see if the session variable is less than some number to determine if the user can open a grid, click a button, etc., etc. It's used in all kinds of show/hide and enable properties. Are you saying that all of that could break for me in a future version?

[Jeff Blackwell]

Re: All session variables protected?

Carol -

While I'm curious to hear Lenny's response, I suspect that the solution would be to cast the numeric as a character type and you could work right around it. It makes sense to me why they might have to go there in order to use IIS - IIS Session variables are Strings as I recall.

That's probably why they are warning us at this early of a stage.

[Lenny Forziati]

Re: All session variables protected?

Yes, Carol, you may need to tweak your code to move forward. Jeff is correct in that it is a limitation in the IIS session management, and that the fix (at least in your case) is pretty straightforward because strings are easily converted to and from numerics.

We are hoping to be able to provide support for additional data types in session variables under IIS, but we cannot guarantee it as of now while we can guarantee that strings will definitely work. We've never said anything other than strings would work, but we haven't actively prevented them in the past either, so we want to provide an early warning now about potential issues that may be encountered when moving forward.

[Pat Bremkamp]

Re: All session variables protected?

Carol,

Thanks for pointing out the search feature. Using it, I was able to convert my two most used session variables from numeric to character in a little under two hours, and while I was at it, I removed the __protected__ which is no longer needed which makes it easier to type and read. As I went through, I found that I had converted numeric to character (to put the value in strings ) about as many times as I now convert character to numeric, so going forward is shouldn't be much of a burden, and I won't have to try to remember which is which. (that's a silver lining statement).

I always wondered why the session variable from security was character even when the value was numeric? Now I know.

Pat

[kingcarol]

Re: All session variables protected?

So, just for clarity... before I change anything. Like I said, I currently have a numeric session variable to determine what a user has access to. Let's call it session.acesslevel (which is not what I really use). So.... if that session variable is changed to a character, will I be able to enable a button only if the session.accesslevel value is a 3 or less as follows: SESSION.ACCESSLEVEL <= 3 in the button's Enable property condition? Or will that fail without doing some sort of conversion to numeric, and where would I do that? Or, do I just put apostrophes around the 3 in the enable condition and, if so, will it evaluate the less than or equal correctly??

[Lenny Forziati]

Re: All session variables protected?

Carol, I think the best way to get your answers is with a bit of interactive window experimentation, as it will show you exactly how character and numeric variables interact with each other. Here's a bit to get you started, but feel free to try some other tests as well.

dim testvar as c
testvar = 4
?testvar
= "4"

?testvar >= 3
ERROR: Argument is incorrect data type [COLOR="#FF0000"]'This means you cannot directly compare the two different types[/COLOR]

?testvar >= "3"
= .T. [COLOR="#FF0000"]'This seems like the correct result...[/COLOR]

?testvar >= "30"
= .T. '[COLOR="#FF0000"]'But this shows that comparing as strings is essentially comparing the alphabetic order of words[/COLOR]

?val(testvar) >=3 
= .T. [COLOR="#FF0000"]'Now [URL="http://wiki.alphasoftware.com/VAL+Function"]val()[/URL] is used to get the numeric value of what is stored in the string for comparison to a number[/COLOR]

?val(testvar) >= 30
= .F. [COLOR="#FF0000"]'And since you are comparing as numbers now, the comparison is correct here as well[/COLOR]

?val("this string isn't a number")
= 0 [COLOR="#FF0000"]'Just be careful about using val() when the variable's content doesn't represent a number[/COLOR]

[kingcarol]

Re: All session variables protected?

Thanks so much, Lenny. That tells me what I'll need to do. It's pretty irritating, though, because my job won't be just 2 hours like Pat's, I'm afraid. I have used that type of condition probably in more than a hundred different places by now and it annoys me that I would have to stop all my other coding and take a bunch of time to comb back through everything to change this... with some chance of missing it in an overlooked place. Can I expect more things in future versions that would suddenly break all of my components? Makes me worry....

[Lenny Forziati]

Re: All session variables protected?

Just to reiterate Carol, nothing is going to suddenly break. You do not need to stop what you are doing to modify existing code. If you never move beyond V11's Xbasic web server, you will never need to make any changes.

We are making customers aware of a potential future issue. We suggest that all NEW code you write from now on uses only character variables. Additionally, if you do plan to move beyond V11's Xbasic web server, you should begin planning updates to existing code at a convenient time in your development cycle.