Closed SamerOrfali22 closed 10 months ago
Hello @SamerOrfali22!
I've conducted tests on the callbacks and they are functioning as intended.
Regarding the callbacks and checks Whenever you open the app (assuming it wasn't already running in the background), all the checks are performed. These checks are asynchronous, meaning they don't wait for each other. If a check fails, the corresponding callback is executed.
Internally, there are two types of checks: one-time and periodic.
One-time checks are executed only once when the app is launched and wasn't running in the background.
Periodic checks are performed regularly, at defined intervals (e.g., every X seconds or minutes).
Even when the app is running in the background, freeRASP continues to perform periodic checks. If a threat is detected while the app is in the background, these checks either report the threat immediately (if possible) or cache the information to report it to the app when it enters the foreground. Please note that the process is slightly more complex due to Android's lifecycle.
Therefore, when you return to the app from the background, the checks are not rerun from the beginning. freeRASP continues with the periodic checks or executes the cached callbacks that occurred during the time the app was in the background. If app was in the background for short amount of time (few minutes) it's quite possible that you hit window during which no check was performed/reported.
However, Business RASP+ is more flexible and allows to run all checks every time you ask for it (so even when going from background). It also contains synchronized checks and many other useful additions.
More about Business RASP+ here.
Took me Two days to figure it out, the Example that came with v5.0.0 omitted one basic initialization ..
@ZeroIntelligence I'm sorry to hear that encountered any difficulties with integration.
Is there anything we could improve in our documentation/example to make the process clearer?
The example demonstrates an advanced initialization that from our point of view, improves the code quality in overall. We didn't find any errors there and it works as intended. Maybe the fact you are pointing to is that the threat listeners are attached in ThreatNotifier and not in the main class - this may be a bit harder to spot at the first glance, however, the functionality is still there. If you wish to integrate freeRASP in a more straightforward way, you can follow our guide in readme - you will not need the ThreatNotifier and you can listen to incoming threats directly on Stream, as hinted here.
Let us know if you have any questions.
Best,
Tomas, Talsec developer
The ThreatNotifier implementation works better for me than the Stream Subscription Listener, i have tried both ways ,
for me freeRasp wouldn't initialize with the TheatNotifier method without initializing the Notifier in main class
this worked for me like charm
*final threatProvider = StateNotifierProvider<ThreatNotifier, Map<Threat, bool>>( (ref) => ThreatNotifier(),***
await Talsec.instance.start(config); ProviderContainer().read(threatProvider); ///////////////// THIS LINE WAS MISSING ,
i believe the Notifier should be initialized after calling Talsec.instance
Hello @ZeroIntelligence,
We weren't able to reproduce the problem you are describing.
Does this happen in our example? E.g. when you clone the repo ad run the app in example folder?
Best, Tomas, Talsec developer
Closing this issue due to inactivity. Feel free to reopen if there are any updates.
I want to block the user from using the application if one of the callbacks happens, and I can't wait for them because they are not Future, so I'm keeping the user in the splash screen for a couple of seconds until the check is finished. but my problem is that when I come from the background the app is not checking again and the callback is not happening again so I'm not able to know if the current device is safe or not after coming from the background. to test it you can try it on iPhone Simulator for the first lunch the callback executes but after doing HotReload => none of the callbacks will execute and the app will lunch normally.