test if cookies can save

Report · Feb 03, 2013

Hi gang,

I'm sort of a rookie at this... delving into the saving of cookies. All's going well, I've got data collecting, sending off to a cookie, and I can retrieve it later.

Howerver, I was wondering what the best method to TEST if cookies can save. I was going to try pushing a tiny bit of data to my cookie right after

import flash.net.SharedObject;

var cookie:SharedObject = SharedObject.getLocal("myCookie");

var mySmallData:uint = 0

cookie.data.smallData = mySmallData

if (cookie.size > 0) {

warningPopup.visible = false

} else {

warningPopup.visible = true

}

It's working locally when I test if from Flash or run the swf from my desktop, but breaks when I run the swf in Chrome from my desktop. Is this even the right way to go about it? It feels clunky.

Be gentle, I'm learning.

dp

Report · Feb 03, 2013

You can use shared objects (a shiny word for cookies) but you can also just use ExternalInterface and let JavaScript manage the cookies.

Cookies are unpredictable and unreliable. Session management is a better strategy because it's so easy to not only disable cookies, but to clear cookies, limit cookies to sessions, wipe out after closing a browser, wipe after a certain number of requests, etc etc.

If it's vital to the function of your site I'd recommend going with sessions.

To answer you, just writing the shared object as you're doing (don't forget to flush() to write it) then testing should tell you. You issue might just be you didn't flush():

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/SharedObject.html#flush()

Report · Feb 04, 2013

Thanks for pointing me in the right direction. I'm not making anything crucial, just a goofy little game, and I'm pretty tied into the shared object, so going to stick with it. I tried the flush approach (code below) but when I try it in Safari in Private mode, the popup doesn't appear.

warningPopup.visible = true

if (cookie.flush() == "flushed") {

warningPopup.visible = false

}

Is using Safari in private mode not a good litmus test this? It won't import any of the date FROM a shared object, so I figured it was not saving TO shared objects.

Report · Feb 04, 2013

Private mode in any browser means cookies are restricted (to various extents). This is the unreliable nature you can't get around. If you detect you can't save a cookie you'll have to use a session approach (pass a unique key in every link, e.g. index.php?k=abcdefg12345) to a database entry of information or even serialize your cookie and encode it while passing it the same way.

Report · Feb 05, 2013

That makes sense, but I'm still just trying to get past that "If you detect you can't save a cookie" part. Why would cookie.flush() return "flushed" if my browser's in private mode?

Thanks,

dp

Report · Feb 05, 2013

Most likely because JavaScript doesn't support an API for private sessions nor understand a browser capable of using cookies but uses them in a very discreet/temporary way. That and plugins edits are often disabled. If you save your (cookie) SO, change URLs and read it back, consider using it for temp storage. If not, revert to sessions.

Remember, JavaScript is on a whole different development path. Private session support will find its way in but it's not standardized. Cookies alone are difficult to deal with because people have cookie-phobia and browsers make removing them so easy.

Cookies are also client-side and instant. They can be set server-side but if you set them with a SO/JavaScript, it's instant and needs no new page load or any server usage at all. If you don't get your result back immediately, that's how you know it's not going to work for you.

I keep recommending cookies because it requires no plugin.

Report · Feb 06, 2013

Sorry, I'm not following at all now. I'm doing this all in Actionscript right in my fla. I do get a "flushed" from running .flush right in my AS, but I would've thought that wouldn't happen in private mode.

Report · Feb 06, 2013

Let's just step back and use a simple Adobe page to show you what shared objects are stored.

Go private, create/flush a SO, then load this url directly in the same tab you just saved the SO from:

http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html

If your SO isn't listed it's not being written at all. If it is, something is restricting access to it.

Chrome seems to fail in regards to this fix, because in private, it really should not be writing objects. A simple write-up about this security breach here:

http://arstechnica.com/security/2010/08/private-browsing-not-so-private/

Quote:
The problem got worse when extensions and plugins were considered. All four browsers tested enabled plugins in private mode, and these plugins can themselves store data that allows both kinds of privacy to be defeated.
One example of such a plugin used to be Adobe Flash; Flash has its own cookie system, and it used to be the case that Flash's cookies did not respect the privacy mode of the browser. Cookies set in private mode persisted, and cookies set in public mode were readable from private mode. Fortunately, Flash has since been fixed, but any plugin could contain similar errors.

I can verify chrome still has an issue disabling SOs. Firefox/IE both initially save the data (probably just to memory) but on page refresh the SO doesn't exist. A page refresh might be the only way you can detect private mode of some sort in use.

So again, use sessions.