Skip to main content
D
Dan74
Known Participant
February 3, 2013
Question

test if cookies can save

  • February 3, 2013
  • 1 reply
  • 1386 views

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

This topic has been closed for replies.

1 reply

sinious
sinious
Brainiac
February 3, 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()

D
Dan74Author
Known Participant
February 4, 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.

sinious
sinious
Brainiac
February 6, 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.


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.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices