AIR SDK 51.1.1 navigateToUrl throws SecurityError

[gosgame]

Hi,

After upgrading AIR sdk to 51.1.1 my calls of navigateToUrl started throwing these errors;

SecurityError: Error #3769: Security sandbox violation: Only simple headers can be used with navigateToUrl() or sendToUrl()

In our case, navigateToUrl is trying to open simple web pages (http).

[gosgame]

Also EncryptedLocalStore.setItem call on an Android device throws an Error.

Error: EncryptedLocalStore internal error

The app seems to behave like a web app instead of an air mobile app.

[ajwfrost]

First part of this was because we are injecting a custom header into all URL requests .. and hadn't tried the 'navigateToUrl' function with that. Simple fix so we can get that out soon.

I've asked someone to look into the second issue here .. this one I thought we had properly checked! did you have any of the new settings for ELS in the app descriptor? (I will assume not, for now..)

thanks

[gosgame]

Thank you for your reply. I wasn't aware of the new settings. I am going to check them.

[ajwfrost]

Ironically, on Windows at least, it doesn't even pass the headers through to the navigateToUrl call when it goes to the browser...

Anyway: for the Android/ELS thing, we're not able to reproduce this one here.. are you able to put a test case together or provide other details on device type etc?

thanks

[marcanw]

I was on the verge to post about the navigateToUrl issue. @ajwfrost Let me know when it's fixed (or if you have a date). Thank you

[JuanCaiza]

@ajwfrost Do you have a quick solution file for navigateToUrl?

[ajwfrost]

An updated release for this should be out later today (within the next hour or so I hope...)

[JuanCaiza]

thanks the bug seems to be fixed with the new version.

[gosgame]

navigateToUrl is fixed after SDK upgrade to 51.1.1.2. Thank you.

But I still get an error while running the game after installing the new package onto the existing one. I assume it is still EncryptedLocalStore error but cannot confirm since debugging is not working on the new SDK.

The game can start again after cleaning the app data through android settings.

I tried adding encryptedLocalStorage settings to application.xml but got an error while packaging;

error 402: Current Android sdk version doesn't support encryptedLocalStorage as xml tag

Which android version do i need?

The settings that i tried to add (which are also written as defaults)

  <encryptedLocalStorage>
    <fallbackMode>always</fallbackMode>
    <storageMode>os_store</storageMode>
  </encryptedLocalStorage>

[wmtj]

navigateToUrl is fixed after SDK upgrade to 51.1.1.2. Thank you.

But I still get an error while running the game after installing the new package onto the existing one. I assume it is still EncryptedLocalStore error but cannot confirm since debugging is not working on the new SDK.

The game can start again after cleaning the app data through android settings.

I tried adding encryptedLocalStorage settings to application.xml but got an error while packaging;

error 402: Current Android sdk version doesn't support encryptedLocalStorage as xml tag

Which android version do i need?

The settings that i tried to add (which are also written as defaults)

  <encryptedLocalStorage>
    <fallbackMode>always</fallbackMode>
    <storageMode>os_store</storageMode>
  </encryptedLocalStorage>

Same too ...

[gosgame]

error 402: Current Android sdk version doesn't support encryptedLocalStorage as xml tag

The reason of this error was the misplacement of the encryptedLocalStorage tag. I moved it to the application root and the package is created.

Nevertheless it didn't fix the error. I also tried setting fallbackMode to never and it became to stuck in a black screen on start.

[ajwfrost]

We're not able to reproduce this black-screen problem but I expect it's due to updating the ELS mechanism.. if you uninstall the app fully and then reinstall it, does that help? And are you trying to access something from the ELS during your start-up code? Can you put that into a try/catch block and report any errors it throws?

thanks

[gosgame]

I upgraded AIR SDK to 51.1.1.3 to see if the changes will fix my case but the crashes continue. I tried to set fallbackmode to always and never but they didn't help (storageMode is os_store).

This is the crash i am getting while setting a json object (with just one data field) to a key;

Exception has occurred. Error: EncryptedLocalStore internal error at flash.data::EncryptedLocalStore$/processErrorCode() at flash.data::EncryptedLocalStore$/setItem()

Screenshot;

I am confused about the new changes about the EncryptedLocalStore. I just want to continue it as it was before. What should be my configuration?

[itlancer]

With AIR 51.1.1.3 EncryptedLocalStore.setItem() doesn't properly: https://github.com/airsdk/Adobe-Runtime-Support/issues/3403#issuecomment-2293704444

[gosgame]

@ajwfrost We need to update our games asap because of Google deadlines but EncryptedLocalStore problem is preventing us to do so. Can you please assist for a urgent fix?

[ajwfrost]

@gosgame We're going through some more testing to try to cover all of the various use cases, but are hoping to get a release out towards the end of next week; I'll post a fix candidate here in the next couple of days in case that helps (also tagging @itlancer fyi)

[ajwfrost]

@gosgame @itlancer below is a link for the Android updates to ELS, hopefully this will help; we were looking to do an official build at the end of this week. https://transfer.harman.com/message/cfBlgNOQNqhUe3z9sm449S

Please let us know of any concerns..

[itlancer]

@ajwfrost For me ELS for Android seems to works fine with this patch. Waiting for full release.

[ajwfrost]

Thanks for the update. Bit of a delay on the release because of an IT issue which appears to be blocking one of our build servers from hooking up to Jenkins... :-( But will try to get this out early next week, we're doing a manual workaround..

[gosgame]

I still get an error while calling EncryptedLocalStore.setItem() in the new SDK. @ajwfrost

I am trying it by installing the new app to a previously working version.

I removed encryptedLocalStorage tag in application.xml to see the default behaviour. Are there any tags that I should add?

[ajwfrost]

@gosgame what platform was that on, Windows? We did end up still with a Windows-specific issue, which could I think be triggered by the above scenario. I can double-check though..

thanks

[gosgame]

The crash is on Android. By the way when I added these flags to the application.xml, the setItem error is gone away;

<encryptedLocalStorage>
    <fallbackMode>never</fallbackMode> 
    <storageMode>os_store</storageMode> 
</encryptedLocalStorage>

[ajwfrost]

Interesting .. so the "default" values if you omit them would be the same as:

<encryptedLocalStorage>
    <fallbackMode>always</fallbackMode> 
    <storageMode>os_store</storageMode> 
</encryptedLocalStorage>

And by the looks of the code, the behaviour you're seeing is "by design":

• if we're trying to set an item, we try to open an existing ELS storage file if it's there.. but on Android if you had previously been using an earlier 51.1 build, this I think will be treated as an internal error
• if you're fine without fallback, then we ignore that error, and just set the item (re-creating the storage file)
• but if you had wanted fallback, this is counted as an error scenario hence the failure is reported back to ActionScript

I am starting to think though, that any failure for us to open an ELS store is going to be non-recoverable anyway, so perhaps we should just ignore the failure and overwrite the file in all use cases? Let me know what you think.. in the meantime, if you catch that error and do a 'reset()', you should then be able to write it on the second attempt.

thanks

[ajwfrost]

Actually a quick update to that, having tried it and checked what's going on internally, the failure happens if we go from 51.0 to 51.1.1.4... and is because we're not able to properly open the store, hence failing if we're meant to be falling back (per the above - I just got the version details wrong).

So yes - if you think we should just ignore this as an error scenario, please let me know, but currently it is possible to catch/reset/try again, and this time it works.

[gosgame]

Thank you for the detailed analysis of the situation. However, I'm a bit confused about the new implementation. Why is it not possible to continue using the old storage in its current form?

Does the error indicate that there is no data stored under that key, or does it mean that the data saved by the previous system cannot be read? If it is the latter, then all the data saved by the previous system will be lost, which is a significant issue.

I believe the way the error is handled is less important as long as the behavior is clearly communicated and understood.

[ajwfrost]

The goal should be that if you don't put in some flags to change the behaviour, then it should continue as it did before. I'll double-check on this specific case as to why we can't open the store from 51.0, I know we had some releases with problems but the 'fallback' should have caught this..

From what we had seen before though, it is the latter of your suggestions i.e. the data itself can't be read. I'll check what OS/versions this might relate to.. It's definitely not an ideal scenario, but the goal was to get ELS into a more sustainable mechanism and to avoid some of the earlier issues that had been reported around it..

thanks

[ajwfrost]

FYI - the problem here was in a slight issue we had in the 51.0 variant when we were writing out the files .. but it should be recoverable, it's just not a format that we would want to continue with. So we can add code to ensure the old data is still available and gets corrected on start-up..

[gosgame]

Thank you for the update @ajwfrost. That is great you found the reason behind it. Looking forward to the recovery code.

[itlancer]

For me all these issues fixed with latest AIR 51.1.1.5.

[gosgame]

It is the same error for me with AIR 51.1.1.5. Is there an update for this problem @ajwfrost ?