Right now, I am using the react-idle-timer library to log a user out after a period of inactivity. However, when I close all tabs or windows associated with my application and wait the idle period, then open up the webapp again, I am still considered an active user. I want to find a way to log a user out if they close the webapps after a certain period of time.
I tried using react-native AppState, but I started my app with create-react-app and I am having issues getting the application to react native.
Any advice?
If your user closes the browser tabs/window, it is like they are killing a process using the task manager: The application has no running instances anymore and there is no possibility to prevent this from happening. Therefore, it is not possible to achieve such a log-out mechanism using a client-side approach.
However, there are some possible solutions to this requirement to log out a user upon inactivity, which highly depend on the authentication mechanisms you use.
If your app is frontend-only (and has no dependencies to any backend services), you can have a „last active“ timestamp in local storage, compare and update it on each action and invalidate the users credentials if necessary.
For session-based log-in, you can make the session expire when the user closes the window (which should be the default behavior). Additionally, you can add a session variable similar to the „last active“ field, which is updated on each action and invalidates the authentication state from server side if necessary.
If you are using token-based authentication, you can tweak the token expiration period and regularly re-issue a new token (probably not best practice, but might be working…)
In general, in terms of security, you should always prefer relying on information saved on the server-side of your app rather than on the client-side. Information in the browser can be easily manipulated by an attacker, while checking for a forced log out on the server-side even works when the user decides to hard-reset their machine (or experiences a power outage, …). And if your server-side is not working anymore one day… well, then you have some bigger problems.
Regarding react and react-native, though they are working pretty much the same and are using the same framework paradigms, they have one major difference: They are compiling for different platforms. Therefore from my experience and from their technical foundation, it is neither easy nor recommended to use components of one of them for the other one. So it highly depends on your use case which of them to use best.
Even though this is not a safe & sound solution, I hope to give you some orientation on your possibilities for such a log out.
Related
I am building my first ever Chrome browser extension and I am struggling to find the right solution for handling authentication. There is a requirement that the extension stay logged in as long as possible, to reduce the need for the user to log in often. This means we would need to use Refresh Tokens. I would very much like to handle all authentication on the background script but this is no longer persistent in MV3 nor does it have access to the DOM.
This being the case, I see these options:
use Auth0 React SDK on the content scripts - this means all my authentication logic will run in a somewhat less secure environment but the token will be handled by the library and I will be able to access it in all my content and popup scripts (if I need persistence across page refreshes, I would still need to use localStorage, I believe). But this means that the background script will not have access to the token and it will need one of the other scripts to retrieve it and send it through a message
implement the Authorization Code Flow with PKCE following the steps in this tutorial on the background script - this will mean that all my auth logic is running in a more secure environment but I don't have a way of storing the token, other than using chrome.storage. It's also a bit tricky to silently retrieve the token (or check if user is still logged in) from the background script (it can be done using an injected iframe and the web_message response type or with chrome.identitybut there are still issues with the redirect_uri which needs to be listed in the Allowed Origin config of the Auth0 app - so you can only easily do this on the pages of the extension).
I know that the recommended solution for an SPA is using the SDK but I would like to know if this is also the right solution for a browser extension. Based on this article on Token Storage, localStorage is dangerous especially due to third-party scripts. Seeing that the MV3 manifest has now removed the ability to execute remote code, is localStorage an acceptable way to store tokens?
I have implemented both options using the docs provided but I am unsure as to what is the best solution, given the changes introduced by MV3.
Thank you
I make a web service and I'm going to use a React. A data for the service will be fetch from my API.
But there is a simple way to find out which endpoints I'm using, and what data I'm sending. This knowledge gives a lot options to make bots for my service.
Is there any option to prevent this?
I know, I can require a signing all requests, but it's also easy to get to know.
This cannot be done. Whatever is done in client-side JavaScript, can be reverse-engineered and simulated.
Efforts should be focused on preventing API from being abused, i.e. throttling or blacklisting clients based on their activity or available information (user agent, suspicious request, generated traffic). If the use of API allows captcha, suspicious clients can be asked for proving their humaneness.
There are half-measures that can be applied to client side application and make it less advantageous for abuse (and also for development).
Prevent unauthorized access to unminified/unobfuscated JS AND source maps. There may be a need to authorize them on per user basis. This will make debugging and bug reporting more difficult
Hard-code parts that are involved in request signing to browser APIs, e.g.:
apiKey = hash(NOT_SO_SECRET_KEY + document.querySelector('.varyingBlock').innerHTML)
This requires bots to emulate browser environment and makes their work much less efficient. This also affects the design of the application in negative way. Obviously, there will be additional difficulties with SSR and it won't translate to native platforms easily.
here two basic preventive measures that you can use.
Captcha
Use a captcha service like recaptcha. so that user can use your website only after passing the captcha test. Its highly difficult for bots to pass the captchas.
Rate Limit Api usage.
Add rate limiting to your api. so that a logged in user can only make 100 requests in 10 minutes, the numbers will depend on you use case
I'm implementing a non VOIP app in iOS 11. As per the nature of my App, I've implemented the startMonitoringSignificantLocationChanges(). All the implementation went well and it is working now.
while terminating the app I'm calling startOrReStartSignificantLocationUpdate()
and I'm restarting significantlocationupdate in didFinishLaunchingWithOptions
also I'm updating location in server in didUpdateLocations event
Location updates is reflected on my server when the App is in foreground or background. It is now reflects even if user kill the App manually. So it works with SLC but
the problem is;
Updates seems to get stopped after a period of time say, 3 - 4 hours. It happens if the user kills the App manually. As per the nature of my App, I need to get it re-initiated up on location change and get the location update to my server.
Is there any category of App which can get this location updates forever in iOS11? I'm thinking about how Moves App in iOS works. Not sure it works perfect with iOS11 though
If you only use “While Using” location access, as far as I understand nothing changes for you. If you use the “Always” access though, and you didn’t provide a “While Using” fallback as you should have… well, you will need to do that now
As Brad Jensen explains in the WWDC talk I mentioned, Apple has decided that forcing the user to give the app “Always” location access is a bad user experience:
Now, a second reason we think that many developers choose to require
Always authorization is they’re simply trying to give their users the
best possible experience (…) but this makes for a very poor user
experience for the users that don’t wish to grant the app Always
authorization. They are forced to choose between granting the app
Always, which is more than they would like in this example, or
granting it Never, which means they don’t get to benefit from any of
the app’s location-based features. And their final option is to grant
it Always and then revoke that authorization after they’re done using
the app. In any case, the user is not having a great time with this
app.
So, when you build your app using the iOS 11 SDK, you are now required to provide an NSLocationWhenInUseUsageDescription key in all cases (if you use location at all). For “Always” access, you can additionally provide a second key, which is now called NSLocationAlwaysAndWhenInUseUsageDescription. If you only provide NSLocationAlwaysAndWhenInUseUsageDescription but not NSLocationWhenInUseUsageDescription, asking for “Always” access will not work:
This app has attempted to access privacy-sensitive data without a
usage description. The app's Info.plist must contain both
NSLocationAlwaysAndWhenInUseUsageDescription and
NSLocationWhenInUseUsageDescription keys with string values explaining
to the user how the app uses this data
Effect on existing apps
Most SDK changes usually only take effect once you recompile your app with the latest version of the SDK & Xcode. This one is different: even if you don’t release any updates this summer, this change will affect you.
Here’s what the user sees when they run existing apps from the App Store in iOS 11 beta and they ask for location access:
The first one is from Foursquare, which has provided both access level options for a long time. In this case, iOS 11 lets you immediately choose “While Using” or “Always”, and since the description texts have not yet been updated with the new behavior in mind, it shows both texts at the same time.
The second one is from Topo Maps, an app that lets you browse hiking maps and find yourself on the map while you’re on the trail. You can imagine it has no reason to track you in the background, but still, the developer has not provided a “While Using” option. iOS 11 now lets you choose that option anyway, but since it might possibly cause some unexpected behavior in the app, it shows a warning that some parts of the app might not work.
If your app has only provided an “Always” key so far, I’d recommend that prepare a transitional update that adds the NSLocationWhenInUseUsageDescription key and makes sure the app works properly in this mode. That way, the user will get a popup like the one in Foursquare, which at least looks less scary.
I'm studying React Native right now, and I'm trying to figure out how to enable the reception of Push Notifications even when the app is closed, just as Facebook does.
I'm a web developer, so I'm not used to mobile apps' "Manifest" logic. Where should I start from?
Thank you!
It seems that since you are a web developer, mobile app is not yet familiar with you. Actually, setting up push notification will require a few more official steps (differently on iOS and Android), and after everything is set, the push notification will happen between Apple server (or Google server) and smartphone's OS (which is iOS or Android), so the push notifications will come to the phone no matter what (without knowing/caring your app is opened or closed ^^)
In the programming code of our app, we can do our logics when the notifications come based on 2 cases: users is using the app or app is not running (not running means users are not using your app, and it is either staying awake in the background or users have exited it completely - e.g. pressing Home button twice on iPhone, and swiping the app away)
Actually, If you want your app to stay awake in the background, you can add some settings to the "manifest"-like files (of course differently on iOS & Android). However, my experiences taught me that keeping the app awake will encourage the users to complain and delete our app (my previous app's user once complained about his iPhone's battery was consumed greatly because of my app ^^)
If you really want to keep your app awake, you can set it in the settings, then in the push notifications' data, you can include extra parameters, and finally in the function of receiving push-notifications in your app, you can do anything with those parameters!
In short, you may just need to config push-notification properly for your app, and Apple/Google will do the rest, either your app is running in background or totally closed, it will receive the notifications. Hope you can find a good solution based on my explanation. If there's still something unclear, feel free to post here some more details on your needs, thanks!
This is the library I'm using with my previous react-native project: (they also have tutorial there ^^)
https://github.com/zo0r/react-native-push-notification
ADDED EXPLANATION: (based on author's needs):
The goal is: the user will register/login in the app, and will subscribe to some future events.
=> whenever users open the app, data will be sent to Apple/Google server to get a token, and you will use this token together with user's subscribe data to send all to your own push-server (you can use PHP or node.js server or whatever)
When an event gets updated a notif. should be sent to all the users who are going to that event. So a notif. aimed to certain users only.
=> like the above answer, data will be sent every time users open app (or change settings, you can do it in your logic of the app, because data will be kept your own push-server, which means on that server, you can even see user list, and can aim to certain users - it depends on what data will be sent to the users from the smartphone, but users may refuse inputting too much information like name, age or email, but it's up to your service's need ^^)
By clicking on it, the app will open and a certain page of the app (pre-existing) will be shown.
=> by default, when an notif. is clicked, the app will be opened for sure, and here once again, you can add extra parameters to the notifications (which is the landing page you need, then in the function of you app, just go there - but it may get extra logics for this. Besides, when to push notification, and which data should be pushed etc. will be controlled by your own server)
It seems like the most complicated part will be the "sending to certain users" one!
=> I explained this already, but you're right, actually it's complicated, because you need to create your own server with lots of API and logics based on your needs, and it need a few more steps (complicated one because you need to register many things with Apple & Google, then adding their Certificates into your own server etc.)
Hopefully you will achieve it, I suggest you play around and truly understand how push-notifications work first (for both sides - your own server and your application) - Good luck, though ^^
I've been putting together a single-page application using React and React-Router and I can't seem to understand how these applications can be secured.
I found a nice clear blog post which shows one approach, but it doesn't look very secure to me. Basically, the approach presented in that post is to restrict rendering of components which the user is not authorized to access. The author wrote a couple more posts which are variations on the idea, extending it to React-Router routes and other components, but at their hearts all these approaches seem to rely on the same flawed idea: the client-side code decides what to do based on data in the store at the time the components are composed. And that seems like a problem to me - what's to stop an enterprising hacker from messing around with the code to get access to stuff?
I've thought of three different approaches, none of which I'm very happy with:
I could certainly write my authorization code in such a way that the client-side code is constantly checking with the server for authorization, but that seems wasteful.
I could set the application up so that modules are pushed to the client from the server only after the server has verified that the client has authority to access that code. But that seems to involve breaking my code up into a million little modules instead of a nice, monolithic bundle (I'm using browserify).
Some system of server-side rendering might work, which would ensure that the user could only see pages for which the server has decided they have authority to see. But that seems complicated and also seems like a step backward (I could just write a traditional web app if I wanted the server to do everything).
So, what is the best approach? How have other people solved this problem?
If you’re trying to protect the code itself, it seems that any approach that either sends that code to the client, or sends the code able to load that code, would be a problem. Therefore even traditional simple approaches with code splitting might be problematic here, as they reveal the filename for the bundle. You could protect it by requiring a cookie on the server, but this seems like a lot of fuss.
If hiding the internal code from unauthorized users is a requirement for your application, I would recommend splitting it into two separate apps with separate bundles. Going from one to another would require a separate request but this seems to be consistent with what you want to accomplish.
Great question. I'm not aware of any absolute best practices floating around out there that seem to outstrip others, so I'll just provide a few tips/thoughts here:
a remote API should handle the actual auth, of course.
sessions need to be shared, so a store like redis is usually a good idea, esp. for fast reads.
if you're doing server-side rendering that involves hydration, you'll need a way to share the session state between server and client. See the link below for one way to do universal react
on the client, you could send down a session cookie or JWT token, read it into memory (maybe using redux and keep it in your state tree?) and maybe use middleware (a la redux?) to set it as a header on requests.
on the client, you could also rely on localStorage to save the cookie/JWT
maybe split the code into two bundles, one for auth, one for the actual app logic?
See also:
https://github.com/erikras/react-redux-universal-hot-example for hydration example
https://github.com/erikras/react-redux-universal-hot-example/issues/608
As long as the store does not contain data that the user is not authorized to have, there shouldn't be too much of a problem even if a hacker checks the source and sees modules/links that he shouldn't have access to.
The state inside the store as well as critical logic would come from services and those need to be secured, whether it's an SPA or not; but especially on an SPA.
Also: server-side rendering with Redux isn't too complex. You can read about it here:
http://redux.js.org/docs/recipes/ServerRendering.html
It's basically only used to serve a root html with a predefined state. This further increases security and loading speeds but does not defy the idea behind SPAs.