Hi everybody,

I am posting this question here, because I have a feeling I read something about my problem here once, but I cannot remember in what topic or thread nor do I find something with the search facilities of the forum.

Here my question goes:
We have installed WF764 on our sandbox. On the logon page to our self service applications we are populating two variables with the userid. Now we have the phenomenon, that the these variables are not stored anymore in WF_USER as it used to be. Both the variables name are beginning with 'user'. When changing this variable name to something else (like 'xxxvar'), then those variables get stored within the cookie WF_USER.

I have a feeling to remember a comment of somebody of you guys in another thread. In this comment it was stated, that the new release is actually behaving like this for variables beginning with some specific strings (like 'user', maybe?). Now I would like to know, wether my feelings are cheating me or not. And if this behaviour is true, is there a possibility to switch it to old behaviour?

Thanks for any response!

Hi Roland,

Has this issue been resolved on your side?

If not, the better channel for assistance would be to open a case with Information Builders' Customer Support Services. You may either contact your local office, or access online at InfoResponse.

Hope this helps.

Cheers,

Kerry

Hi Kerry,

Thanks for your reply.
No, it didn't get resolved.
Yes, we have already opened a case with our local CSS.

I opened this thread here because I have this feeling of having read something similar like our problem, but I wasn't able to find it. So my hope was to trigger a response by that person.
Unfortunately I seem to be unlucky.

Thank you anyway. When resolved I will post it here!

Roland

I have just been testing WF_USER cookie in 764 on 2003 server. In this test I happened to have variables user_name, userid and usertype which worked perfectly. Maybe it's unix specific.

What are the specific names you are having an issue with?

(Due it issues in the past, I now always use a naming convention of WFC_variableName in an application for variables in WF_USER)

In the administrator console you can pass variables in the &IBIC_REPORT_USER and &IBIC_REPORT_PASSWORD. Just make sure you clear the cache afterwards to make sure the changes take affect.

Alan, jbanas6,

Thanks for your replies.
Just to keep updated:
The problem occurs because we are manipulating those variables in site.wfs. As stated by IBI WF is sort of hiding variables of this type when manipulated in site.wfs. This is new behaviour in WF76 to fix some security leaks (we do not understand 100% why this is and why this is done this way).
In our site.wfs we are calling a Java procedure that checks the user and the called focexec against a table with the information wether the user is allowed to use that specific focexec. After this security exit procedure we are setting some variables according to the result of the check.
So we are in big trouble now. But IBI is working on it.

I will let you updated.

Ah.

Please keep us informed on this, it might affect one application I have.

(Don't forget you can keep WF_USER maintained manually if all else fails.)

Manually

What exactly do you mean by that ?

WF_USER is a cookie, and as long as it is plain text (not encrypted by WebFOCUS), it is accessible with js, as any other cookie.

So if you have a value from a form that you want to keep permanently for a session, you can use js to add to it, or create WF_USER new. The name/value pairs are then available as &vars in a WF session, just as &vars set in WF_USER are available in js.