This document was generated from CDN thread
Created by: Kevin Pickard on 26-11-2013 07:46:03 AM
We are seeing corrupted or missing authorization information coming from Finesse and are wondering if this is a bug or expected behaviour given the description of Prefs() in the API guide. From the Finesse Web Services Guide we see the following.
"The gadgets.Prefs class provides access to user preferences, module dimensions, and messages." ... and then later. "Do not use preferences to persist critical application data. This data is stored in the browser and may be manually purged by the user at will. This storage is meant for preferences (similar to the type of information that is typically stored inside a cookie), and not for complex application data. Additionally, when the browser runs out of the allocated storage space, this data is purged."
It is the later warning that is causing us some concern. We are currently not storing any of our own information in preferences but rather accessing information that is being provided by Finesse. In particular we are getting the authorization string (as shown in the snippet below).
var _gadgetPrefs = new gadgets.Prefs();
var auth = _gadgetPrefs.getString("authorization");
What we are seeing is that sometimes this authorization string is either empty or truncated. This behaviour seems to happen on some client machines more than others and so we are wondering if it is due to browser memory cleanup. We are seeing this in both UCCE and UCCX versions of Finesse.
Are we not able to reliably count on this information being present and intact?
Subject: RE: Corrupted or missing Authorization
Replied by: Gary Olmsted on 26-11-2013 09:58:36 AM
Hey Kevin,
I think this contradiction is accidental and taking these both together does make it confusing. Gadget Preferences are dealt and used by the container in two ways:
1) They are passed into the Gadget via URL parameters by Shindig, then pulled back out (again by the container) to reconstruct the Gadget Prefs object on the Gadget side. So, in this way, they should be intact when they arrive into the gadget.
2) When you set Gadget Prefs yourself, they are typically also stored in the form of cookies on the browser so that they are available later. Cookies are obviously temporary, so that is the reason for the "don't store complex/important information". What is really means is "...that you intend to keep across login sessions".
Let's focus more on the problem you are seeing, as that may be related. Since you mention UCCE and UCCX versions, then I presume you are workign with pre-FCS builds of Finesse (as anything out there doesn't formally support UCCX (yet)). One thing that we changed in 10.0 (for security reasons) is that we moved the authorization into a cookie. For backwards compatibility reasons, in our Finesse JS Library, we extract it out of the cookie and put it into the prefs inside the gadget. If you are seeing this empty/truncated, then this actually may be a manifestation of a cookie persistance problem (and/or corruption).
If you are on EFT, then where did you get the Finesse JS Library you are using with your system? Do you have a system you can reliably reproduce this one? Since you are messing around with 3rd Party Gadgets would you be interested in doing a little debugging for us? If so, please let me know, I would like to know if this is a Finesse JS Library incompatibility, or a real problem.
Thanks!
Subject: RE: Corrupted or missing Authorization
Replied by: Kevin Pickard on 26-11-2013 10:39:07 AM
Yes Gary we would be willing to help with debugging. Do you want to take this offline via email?
Subject: RE: Corrupted or missing Authorization
Replied by: Gary Olmsted on 26-11-2013 12:47:40 PM
Sure, I don't see a way to message you here. How do CDN members get connected (without explicitly posting my email address here)?
Subject: RE: Corrupted or missing Authorization
Replied by: Kevin Pickard on 26-11-2013 02:04:22 PM
I guess as a Cisco employee you don't necessarily have access to CDN member profiles (which I guess is a good thing). Perhaps David Lender can forward my email address to you. 🙂
Created by: Kevin Pickard on 26-11-2013 07:46:03 AM
We are seeing corrupted or missing authorization information coming from Finesse and are wondering if this is a bug or expected behaviour given the description of Prefs() in the API guide. From the Finesse Web Services Guide we see the following.
"The gadgets.Prefs class provides access to user preferences, module dimensions, and messages." ... and then later. "Do not use preferences to persist critical application data. This data is stored in the browser and may be manually purged by the user at will. This storage is meant for preferences (similar to the type of information that is typically stored inside a cookie), and not for complex application data. Additionally, when the browser runs out of the allocated storage space, this data is purged."
It is the later warning that is causing us some concern. We are currently not storing any of our own information in preferences but rather accessing information that is being provided by Finesse. In particular we are getting the authorization string (as shown in the snippet below).
var _gadgetPrefs = new gadgets.Prefs();
var auth = _gadgetPrefs.getString("authorization");
What we are seeing is that sometimes this authorization string is either empty or truncated. This behaviour seems to happen on some client machines more than others and so we are wondering if it is due to browser memory cleanup. We are seeing this in both UCCE and UCCX versions of Finesse.
Are we not able to reliably count on this information being present and intact?
Subject: RE: Corrupted or missing Authorization
Replied by: Gary Olmsted on 26-11-2013 09:58:36 AM
Hey Kevin,
I think this contradiction is accidental and taking these both together does make it confusing. Gadget Preferences are dealt and used by the container in two ways:
1) They are passed into the Gadget via URL parameters by Shindig, then pulled back out (again by the container) to reconstruct the Gadget Prefs object on the Gadget side. So, in this way, they should be intact when they arrive into the gadget.
2) When you set Gadget Prefs yourself, they are typically also stored in the form of cookies on the browser so that they are available later. Cookies are obviously temporary, so that is the reason for the "don't store complex/important information". What is really means is "...that you intend to keep across login sessions".
Let's focus more on the problem you are seeing, as that may be related. Since you mention UCCE and UCCX versions, then I presume you are workign with pre-FCS builds of Finesse (as anything out there doesn't formally support UCCX (yet)). One thing that we changed in 10.0 (for security reasons) is that we moved the authorization into a cookie. For backwards compatibility reasons, in our Finesse JS Library, we extract it out of the cookie and put it into the prefs inside the gadget. If you are seeing this empty/truncated, then this actually may be a manifestation of a cookie persistance problem (and/or corruption).
If you are on EFT, then where did you get the Finesse JS Library you are using with your system? Do you have a system you can reliably reproduce this one? Since you are messing around with 3rd Party Gadgets would you be interested in doing a little debugging for us? If so, please let me know, I would like to know if this is a Finesse JS Library incompatibility, or a real problem.
Thanks!
Subject: RE: Corrupted or missing Authorization
Replied by: Kevin Pickard on 26-11-2013 10:39:07 AM
Yes Gary we would be willing to help with debugging. Do you want to take this offline via email?
Subject: RE: Corrupted or missing Authorization
Replied by: Gary Olmsted on 26-11-2013 12:47:40 PM
Sure, I don't see a way to message you here. How do CDN members get connected (without explicitly posting my email address here)?
Subject: RE: Corrupted or missing Authorization
Replied by: Kevin Pickard on 26-11-2013 02:04:22 PM
I guess as a Cisco employee you don't necessarily have access to CDN member profiles (which I guess is a good thing). Perhaps David Lender can forward my email address to you. 🙂