I'm developing a reactjs based application. I want to limit the login from multiple devices at one time to an account. So I need to have an ID that is unique and fixed on device.
I also want the user to stay logged in on one device, so I can not use IP address.
Also, I've already limited access from several browsers.
Thanks a lot. Also, sorry for my English.
This check can't be implemented on client side of the application.
On the server end, you can get IP address from requested payload. You can store the IP address against the session in In-memory databases like redis or memcache. Now, create an intermediate check at login controller where you can block the user if he/she has logged in more than certain number of IP addresses.
Related
This is for a messaging web app. Is there a universal ID assigned to each device
that can be pulled through a web browser, which is brand/operating software agnostic?
I'd like to grab a unique ID related to a user that visits my website and save it to my database as that unique user for that device. Is this possible?
My goal is to assign users based on them accessing through a given device rather than signing up with a username. Theoretically, everyone is a user as soon as they access the site.
It's a messaging app run through the mobile web browser only but I don't want to hassle users through a sign up or login process. The device accessing the site would prompt me to send them data based on their user profile.
signInAnonymously seems appropriate for that.
If there is already an anonymous user signed in, that user will be
returned; otherwise, a new anonymous user identity will be created and
returned. https://firebase.google.com/docs/reference/js/firebase.auth.Auth#signinanonymously
Due to the unauthenticated nature of this kind of user, they are not
transferrable across devices.
https://developers.google.com/android/reference/com/google/firebase/auth/FirebaseAuth#public-taskauthresult-signinanonymously
A user's UID never changes. So after you sign in a user anonymously,
the UID will remain the same until you call signInAnonymously again or
until you call signout. https://stackoverflow.com/a/47856853/11136299
Beginner question here. I’m wanting to build an app that will be an intranet of sorts for a 70 unit restaurant chain. What I’m needing is for each physical restaurant location to see data posted to a MongoDB DB and show on a page in the store within a screen hanging on the wall. This data will be specific to each location such as announcements, catering orders that need to be filled by that store, etc... my question is, how do I create routes so that each individual store will see only their data without having to create 70 different routes or use authentication to utilize user IDs?
Trying to avoid user logins and:
“/store1”
“/store2”
“/store3”
Etc...
Seems like I could query a site ID or something like that
Hope this make since.
If you're talking about one centrally located server that is accessed by all 70 restaurants and you want to have the same routes for all, then you need to decipher some other clue from the request to figure out which restaurant it is that is making the request.
Since you have nixed authentication, I will assume that there are no security concerns here - that this is on an intranet only accessible by restaurant employees.
So, here are the clues you could get from any given request to decide which restaurant's data to show:
Cookie that contains desired restaurant ID.
Query parameter that contains desired restaurant ID.
IP address of request to discern which restaurant the request is coming from.
Separate sub-domain for each restaurant (all pointing to the same host).
Here's more info on each option:
Cookie
In this implementation, if a client arrives with no cookie set for the restaurant ID, then you take them to an opening page where they select which restaurant they want to see the data for and you ask the user to manually select the desired restaurant. Then, you set a long lasting cookie in that browser and from then on (as long as the cookie is not removed), your server can default to showing them info only for their restaurant.
Query Parameter
In this implementation, you use some initial restaurant specification like in the cookie option and then you generate pages where all the links have a query parameter specified in them that lists the restaurant ID (likely using a template system). This is generally not favored these days over a plain cookie system.
IP address
If all your restaurants have their own sub-network (presumably some sort of broadband connection connecting to a central server over some sort of private connection, then you could perhaps build a small table of restaurant source IP addresses so you could identify which restaurant was making the request purely by the IP address of the request. This may or may not be feasible depending upon your network topology. This would be much more automatic than any of the other options.
Separate sub-domain
This would work somewhat like the cookie-based option, but instead of setting a cookie, once the desired restaurant was selected, you would redirect to a subdomain specific to that restaurant. All sub-domains would still point to the same host, but the host could identify the desired restaurant from the sub-domain making the request. Similar to the query parameter option, you'd some template system on the server side to rewrite all links to include the proper sub-domain so you'd stay on the same sub-domain as you navigate.
Of all of these options, the IP address scheme is the only one that would be completely automatic, but may or may not be feasible depending upon your network topology. Of the other choices, the cookie is the most straightforward to implement because the page links themselves don't have to be rewritten.
Enterprise Configuration
In an enterprise scenario where you "manage" any browser that is approved for use, you may also be able to pre-configure the browser in each restaurant to automatically provide some identification (either a custom header or a cookie) and your server could use that identification info to determine which restaurant was making the choice. This would require accessing your site only through pre-configured and approved and properly maintained browsers (which may be more pain than it's worth).
For example, here's how you would configure a custom header on all requests with Microsoft Edge.
We are developing in-house web-based application for viewing data reports while targeting on smartphones and tablets. Our customer asked us for possibility that only certain devices could access the content. Hence we use technologies based on javascript/HTML5 we are no capable of reading unique ID like IMEI or device uuid. The idea is to be able to automatically create time-independent fingerprint of device with above mentioned technologies.
The question is are we able to create unique device fingerprint with javascript/HTML5?
The clue might be information available or known by browser (e.g. http://browserspy.dk/)
You can use the fingerprintJS2 library, it helps a lot with calculating a browser fingerprint.
By the way, on Panopticlick you can see how unique this usually is.
It looks like the phoneGap plugin will allow you to get the device's uid.
http://docs.phonegap.com/en/3.0.0/cordova_device_device.md.html#device.uuid
Update: This is dependent on running native code. We used this solution writing javascript that was being compiled to native code for a native phone application we were creating.
You can use this javascript plugin
https://github.com/biggora/device-uuid
It can get a large list of information for you about mobiles and desktop machines including the uuid for example
var uuid = new DeviceUUID().get();
e9dc90ac-d03d-4f01-a7bb-873e14556d8e
var dua = [
du.language,
du.platform,
du.os,
du.cpuCores,
du.isAuthoritative,
du.silkAccelerated,
du.isKindleFire,
du.isDesktop,
du.isMobile,
du.isTablet,
du.isWindows,
du.isLinux,
du.isLinux64,
du.isMac,
du.isiPad,
du.isiPhone,
du.isiPod,
du.isSmartTV,
du.pixelDepth,
du.isTouchScreen
];
I have following idea how you can deal with such Access Device ID (ADID):
Gen ADID
prepare web-page https://mypage.com/manager-login where trusted user e.g. Manager can login from device - that page should show button "Give access to this device"
when user press button, page send request to server to generate ADID
server gen ADID, store it on whitelist and return to page
then page store it in device localstorage
trusted user now logout.
Use device
Then other user e.g. Employee using same device go to https://mypage.com/statistics and page send to server request for statistics including parameter ADID (previous stored in localstorage)
server checks if the ADID is on the whitelist, and if yes then return data
In this approach, as long user use same browser and don't make device reset, the device has access to data. If someone made device-reset then again trusted user need to login and gen ADID.
You can even create some ADID management system for trusted user where on generate ADID he can also input device serial-number and in future in case of device reset he can find this device and regenerate ADID for it (which not increase whitelist size) and he can also drop some ADID from whitelist for devices which he will not longer give access to server data.
In case when sytem use many domains/subdomains te manager after login should see many "Give access from domain xyz.com to this device" buttons - each button will redirect device do proper domain, gent ADID and redirect back.
UPDATE
Simpler approach based on links:
Manager login to system using any device and generate ONE-TIME USE LINK https://mypage.com/access-link/ZD34jse24Sfses3J (which works e.g. 24h).
Then manager send this link to employee (or someone else; e.g. by email) which put that link into device and server returns ADID to device which store it in Local Storage. After that link above stops working - so only the system and device know ADID
Then employee using this device can read data from https://mypage.com/statistics because it has ADID which is on servers whitelist
There are already numerous questions about jQuery cookie popups, so no need to go into any detail about that functionality. What I want to know is if this is the only way jQuery can handle popups only once per user or a time-based popup per user. I.e. the popup loads when the user first comes to the site and then doesn't load again for a week.
I know there is IP validation, but can jQuery do IP validation and if so, can you point me to a resource? I've searched here for jQuery popup IP validation and so far I haven't turned up anything.
I've said it countless times before and I'll say it again: IPs are a data delivery mechanism, not an identification or authentication tool. IPs are not guaranteed to be unique or stable in any way and are entirely unsuitable for identifying individual users at one machine.
You need to store an identifier on the user's machine somehow to remember for that particular user what he did or didn't do. A cookie is the most obvious answer, local storage, WebDBs, Flash cookies etc. are alternative fallbacks.
I must agree with deceze, considering a company for example could use a single IP while 10+ computers are connected to the web through this IP-address. So if an employee would visit your website the other 9 won't get to see your pop-up because someone with the same IP already visited your website.
But regardless of this being the right approach or not, to get back at you´re question, I came across this SO answer:
How to get client IP address using jQuery
It looks relative easy to get a vistors IP address, even though you should consider you're dependent on a third party this way.
This has more to do with an understanding of how web browsers work and less to do with JQuery. What you need is a way to identify a user. The easiest and most accurate way is a cookie. Something that only the user will have. Plus, you're trying to trying to do this on the client side. The only way for javascript to persist data across requests is via cookies, and for some browsers an Html 5 data persistance structure like IndexedDB.
If you can program on the server you can try to do IP lookups but you potentially get one identifier for multiple devices which can be multiple users. This is because it is common for multiple people to use the same IP (think about how many devices are connected to your home router). You can get more accurate by using the http header value for user-agent. These values are not accessible via javascript.
It may help you to get a better understanding of how http requests and responses.
I need to access an api which requires http authentification on a per user basis using a jquery mobile api.
I plan to make the app available as a website as well as packaging it in Cordova for various devices.
If I have a login form which captures the username and password and store this as a javascript variable, is there any way this data could be exposed?
If so, what's the best alternative to handle storing the users authentification details? I am reticent to build an intermediary server if I don't have to.
Many Thanks. :D
I would suggest not storing the username or password in the localStorage, but instead to store an access token. Access tokens can be updated and changed frequently, it also doesn't reveal who the user is or what their hashed password is.
Besides iOS Keychain or if you're coding it for a non-iPhone device for added security you can:
Change the access token at each login and each time the app is used
Store the device ID in the server database (see http://docs.phonegap.com/en/2.2.0/cordova_device_device.md.html#device.uuid)
Clear the localStorage and request a new login if the access token or device ID doesn't match the data stored in the database
Make sure you don't store the device ID in the localStorage.
For added security you can also store the user's IP address in the database and check (server side) if the IP address matches, but this might too much since the user would have to login every time they connect to the internet in a new location or if their IP address changes.
Storing the IP address in the server database then checking if it matches (server side) would probably be the safest since it wouldn't matter if someone got hold of the localStorage data.
So I understand you don't control the backend you log in to? If you do, I would be more inclined to send username/password once, and then store some access token that will allow you subsequent access.
If you don't control the backend, you're stuck with storing username/password. I would say, setting them in localStorage is as safe as it gets (which is, admittedly, not very safe. Then again, if your login doesn't happen on HTTPS, I would be more worried about passwords leaking there than from the device itself). You could make the passwords harder to find, not call the variables "username/password", encrypt them in javascript, obfuscate your code. But in the end, they can always be retrieved without too much effort with the right access to the device.
After packaging as native app, you have more options, e.g. iOS keychain: http://shazronatadobe.wordpress.com/2010/11/06/ios-keychain-plugin-for-phonegap/