SecureStore cleared after expo-cli restart?

  1. SDK Version: SDK 38

  2. Platforms(Android/iOS/web/all): At least Android

Has SecureStore functionality changed from past? In my application that I develop, I seem to be losing SecureStore content every time I restart expo-cli. As long as I keep expo-cli running, I can restart, force stop etc my expo client & application on my android phone. But once I stop expo-cli and start it again, and I try starting application on phone again, there isn’t anything in SecureStore.

Previously SecureStorage has been persistent between expo-cli restarts. So I’m curious has something changed. There isn’t anything clearly documented in https://docs.expo.io/versions/latest/sdk/securestore/ either.

If it could be confirmed that this is how it should work (and it has been changed to work like that), I’d be happy to know. Currently I’m trying to figure out what kind of bug I might have in my code.

Hey @kerberos,

This should not clear your SecureStore values. Can you see if you can replicate this in a freshly created project?

Cheers,
Adam

I initialized fresh project, and made simple test. Behavior is still same, if I close down expo-cli and start it again, SecureStore seems to be empty. App restarts in Expo client works as expected.
Whole repo can be found here:


It is just initialized tabbed project, and added useEffect to load content of SecureStore, as well button to save value and another to force read value.

Actual code is also here, if there is something obviously wrong:

import * as React from 'react';
import { Button, StyleSheet } from 'react-native';
import * as SecureStore from 'expo-secure-store';

import EditScreenInfo from '../components/EditScreenInfo';
import { Text, View } from '../components/Themed';

export default function TabOneScreen() {
  const [savedValue, setSavedValue] = React.useState();

  React.useEffect(() => {
    const getValue = async () => {
      const secureValue = await SecureStore.getItemAsync('exampleKey');
      setSavedValue(secureValue);
    }

    getValue();
  }, []);

  const saveToSecure = async () => {
    await SecureStore.setItemAsync('exampleKey', 'foobar');
  };

  const readFromSecure = async() => {
    const secureValue = await SecureStore.getItemAsync('exampleKey');
    setSavedValue(secureValue);
  }

  return (
    <View style={styles.container}>
      <Text style={styles.title}>Tab One</Text>
      <View style={styles.separator} lightColor="#eee" darkColor="rgba(255,255,255,0.1)" />
      <EditScreenInfo path="/screens/TabOneScreen.tsx" />
      <Text>
        This is saved value:
        {savedValue}
        End of Saved value.
      </Text>
      <Button
        onPress={() => saveToSecure()}
        title="Save to SecureStore"
      />
      <Button
        onPress={() => readFromSecure()}
        title="Read from SecureStore"
      />
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    alignItems: 'center',
    justifyContent: 'center',
  },
  title: {
    fontSize: 20,
    fontWeight: 'bold',
  },
  separator: {
    marginVertical: 30,
    height: 1,
    width: '80%',
  },
});

I’d appreciate if you can have a look of this @adamjnav, and hopefully it is just some coding error from my end. Then it is (hopefully) easily fixed, and documentation improved so those who come afterwards get it correctly right away :slight_smile:

Hey @kerberos,

I just cloned your repo and tested it with my Galaxy S8 and I’m seeing the value foobar persist across expo-cli instances. What device are you using?

Cheers,
Adam

My testing device is OnePlus 3T (Android version 9, OxygenOS 9.0.6). I’ve used same device past few years.

I didn’t have this kind of problem with SecureStore before summer, as I was working on it already back then. I started now with upgrading to SDK 38 and upgraded to React Navigation 5. Then I noticed this problem with SecureStore.

I’m not sure where to start debugging this further. I had feeling before that SecureStore wasn’t project specific, but didn’t have time to double check that when I noticed it before holidays. Now I read from docs that it is project specific, so is that changed/fixed (haven’t gone to source yet to see how it is possibly changed).
Do you know what determines which project in Expo client belongs to which code, and how it is identified? Maybe I can track if that identifier changes, if I just know what it is & how to print it out. :slight_smile: Any insights @adamjnav?

Mhh… now that I tried using Tunnel option instead of LAN, it seems to be persistent. At least my data hasn’t disappeared. And if I switch to LAN once it has been started with Tunnel, data persists.

Interesting. I’ll try reproducing this on my end. Thanks for continuing to follow up on this mystery.

This seems to be tricky one indeed. I just started my project, LAN mode on first. I got initially error that packager isn’t available, but it was trying to use tunnel url. Using developer tools I switched to tunneling, and restarted expo client. App loads, and SecureStore was empty. I toggled back to LAN, restarted expo client and app loads, and data in SecureStore is there (I didn’t populate it while I was in tunneling).

I’d love to get bottom of this, even as things ‘kind of work’. It is still annoying when starting developing session. And also makes me wonder what happens to SecureStore, what changes so data isn’t always accessible.

Edit:
I just wiped cache & storage from my phone for Expo client. I was trying to figure out that packager not available through tunneling. And at that point I noticed that indeed, error message changed that packager not available through LAN ip. Which then made me check that indeed, I didn’t have proper PortProxy for that port. Adding that, and now it seems to connect. However, once again SecureStore was empty, and if I restart expo-cli, it is empty after restart.
So there seems to be some persistense in expo client, that it tries to keep using tunnel address for project, even if it is restarted and switched to LAN. That’s why my project had problems to not work before I started with tunneling in first try, then switching LAN. Apparently part of connectivity kept going through tunnel.
Which then also makes me think is there some mechanics for accessing SecureStore depending method/url, which could cause my problems? My development happens inside WSL2, so I need to portforward so LAN can access it. Maybe there happens something, which makes app think it is fresh installation, and not accessing SecureStore that has already been populated… :thinking:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.