Develop Reference

How to detect another session is ongoing from another browser tab using Parse Server error

I'm trying to auto logout an app if user logged in from another tab or browser.
I'm using react-idle-timer and Parse Server.
I'm not sure if this line of code will be useful
Parse.Error.INVALID_SESSION_TOKEN
I can access session token via localStorage
const res = await Parse.Cloud.run('login', values);
console.log(res.session);

You can't differentiate a request from a different tab within the same browser. It will share the same session token and be indistinguishable from any other request. Requests made from different browsers will have different session tokens and if they store some user info you can determine which ones belong to which user.
If we reframe your question it sounds like you only want to allow for one active login per user. This requires a centralized or clustered session management solution that supports preventing multiple concurrent sessions.
If you will only ever have one backend server or you are using a shared database to store sessions, then you can do this a bit easier depending on what you are using for session management since all sessions will be available on the one server.
It is not clear to me if your users are connecting directly to parse server. If they are you will most likely need to modify parse-servers code directly to support this.
In general this is a silly idea. Unless you have a legal requirement to do so I would not advocate worrying about this. Bypassing this is usually as easy as copying around a session token.

How to implement a client to server connection that is secure and syncs

I’m struggling to understand how the pouchDB interactions should be implemented. Say I want an offline-first app with syncing and auth, would I need to implement a middleman such as a node server to ensure my credentials to my main server are protected as having a PouchDB on the client with new PouchDB(‘name’, ‘https://username:password#server/dbname’) my creds to my main database are exposed. Would it be better to connect to a node server and that decide wether or not to allow access?
How would this be done? Can I handle a direct connection to the server with auth and it be secure? Or is a middle man needed to ensure security.
If a middle man is needed will you need to implement a sort of api i.e
//client
const db = new Pouch('days')
db.sync(remote)
//server
app.get('/db/days', (res, req) => // do some pouch stuff for each db)
https://github.com/pouchdb-community/pouchdb-authentication

Somewhat simplified, if your application is backed by an application 'master' database and it runs using a single set of credentials, you need a middle layer: you will then need to multiplex all users' data into a single database.
Applications backed by CouchDB/Cloudant often instead use the 'database-per-user' pattern, meaning that each application user have their own database, and their own credentials, meaning that a lot of things become simpler, conceptually, and a middle layer might not be required.
Note that the 'database-per-user' pattern needs some thought to scale well if you intend to cater for millions of users.
On Cloudant you can also use API keys to define access.
If you want the simplicity of the db-per-user pattern without (some of) the drawbacks, you may be able to draw some inspiration from Cloudant Envoy (https://github.com/cloudant-labs/envoy) -- a thin proxy that multiplexes users' data into a single db, whilst still presenting the db-per-user API surface outwards. Disclaimer: I'm one of the authors of Envoy.

Another approach that I use depends on crypto-pouch (https://github.com/calvinmetcalf/crypto-pouch) to encrypt all of your databases on the client. The first time the site is visited, username/password is required to access a cloud couch instance and get things installed on the client.
During this process, a pouchdb database is created on the client for each possible user (retrieved from the cloud couch instance), with each database encrypted with the user's password, and in each database is placed a single document that contains a master password. In addition to these user databases, the 'main' database that stores real data is created and encrypted with the master password.
Subsequent visits to the site whether online or offline, will require the user to enter their username/password, which will attempt to unlock the appropriate user database and get the master password, which is then used to unlock the main database. Only with the master password can the data be accessed and a sync performed to the cloud instance.

Creating database model with Mongoose

I have a node.js app that is essentially a sketchpad and currently I'm working on a feature to enable to save all of the sketches they've drawn during a "session" to a database so they can pick back up at a later time where they left off. I'm using a MongoDB database that I'm connecting to via the Mongoose ORM.
The server is started up in the file main.js which is currently where I'm opening the connection to the DB; however, the code for the saving of sketch data (which is currently just being saved to a JSON file on the server) is in a separate file. Based on this tutorial it seems that the code for the creation of models for a document are to go inside of a callback function that is run once the connection is open. But given that the logic for saving sketches in the app is in a different file from where the connection is being opened and since it says here that model instances aren't created/removed until the connection is open, it seems that there would either have to be a way to open different connections opened to create the models or that there would need to be a way to initiate the creation of the model for the sketches from the connection callback code in main.js.
I'm very new to MongoDB and Mongoose so I'm not sure if this is the correct way to think about creating models but given the needs of the feature, what would be the correct approach to opening the connection to the database and saving the sketches to the database once the save sketch function is called?

You may be overthinking this.
Just open your mongoose connection (a shared connection pool) via a mongoose.connect call during app start up and then create and save your Mongoose models whenever. Your models will use the shared connection pool as needed and will wait until the connection is established if necessary.

Computer-specific javascript execution

Is there a way for javascript to access a variable left by the user of a specific computer? I know that system variables are out of the question.
Currently I have a POS web-app that sends HTTP HEAD requests to the server specifically for the purpose of updating the pos terminal's display pole unit.
The app:
1) Sends HEAD request to the server
2) The server receives the request with the payload and writes to a virtual port which is connected to the pos terminal's LAN > COM port which in turn writes to the pole
However when other devices like mobile phones and laptops use the pos app, all of them are sending these requests every time a line item is changed in the form. That's a lot of useless requests (because these computers don't have their own display pole).
I'd like it so that the JS can search for a specific variable that the user can put in their system. If it's there, send the request. If not, don't even try.
Something along the lines of a browser addon maybe? As in "for this domain, set this variable".

For security reasons, plain Javascript in a web browser cannot access things outside of the browser environment. A browser add-on can access things outside of the browser so it could create an interface for some outside setting.
It sounds like what might make more sense is for the pos terminal to specify a slightly different URL when it uses the POS web app and that different URL (say a query parameter) would tell your app server to place a Javascript variable in the page indicating that this use of the app does have a display pole unit attached so it should do whatever one would do when that is connected.
Meanwhile, the publicly known URL that is used from a laptop or a mobile phone would not have that special parameter in the URL and thus the Javascript in the page could know that it is not connected to a display pole unit and should act accordingly.
You can have the identical web app for the two classes of users with this one configuration variable set differently based on what URL initiated the session.
Other places you can store configuration info in the browser are cookies and LocalStorage. So, the setup process for the pos terminal could cause a LocalStorage value to get set such that your Javascript could tell from that LocalStorage value that this browser is connected to a display pole unit, but the mobile phone/laptop browsers would not have that LocalStorage value set so the Javascript could act accordingly when they were using the app.
Here's another idea. I don't know what kind of browser is in your POS terminal, but if it has a unique user agent string or it can be configured to have a unique user agent string, then your Javascript in the page could check navigator.userAgent and examine it to see if any particular markers were present in the string that indicates this is the POS terminal browser, not some other browser.
Install a browser custom browser plug-in (that doesn't have to do anything except be present with a known name) in the POS terminal browser. Then, use Javascript to detect whether that plug-in is present. If so, you know to act like it is connected to a display. If not present, then no display attached.
To summarize the options:
Use a query parameter on the URL when accessing the webapp from the pos terminal. This would tell your Javascript that there is a terminal attached. You could also then set a cookie whenever you see the query parameter such that other pages (without the query parameter, but loaded from the same device) would see the configuration too.
As part of the setup process for the pos terminal, run a page that would set a cookie to tell the JS that this viewer is the pos terminal.
As part of the setup process for the pos terminal, run a page that would set a value into LocalStorage to tell the JS that this viewer is the pos terminal.
Add some custom indicator to the user agent string in the POS terminal browser that your Javascript can then detect.
Install a custom browser plug-in on the POS terminal which your page Javascript can detect the presence of and act accordingly.

Which (if any) Javascript storage API (Google Drive, Dropbox, OneDrive) provides automatic syncing?

I have an application that was developed using HTML and javascript. What I need now is to make use of a cloud storage system to access a user's files, which could either be using Google Drive, OneDrive or Dropbox.
One of the requirements is that the application should sync so that new files are added automatically and deleted files removed etc. The sync should be automatic, and there should be no need to poll for changes in the code "manually".
I have determined (as far as I can tell) that with the Dropbox Javascript API, you have to poll for changes and then pull the changes. It seems also with the Google Drive Javascript API that you need to watch for changes and then get those changes. I was leaning towards using OneDrive, but my big problem with that API is that you can (well, so it seems) only access files through a file picker, and I need to get the files without involving the user.
Can anyone confirm the above?
If not, if you need to poll for changes, which would be the best API to use?
And just if anyone has an idea, how often should this be done, and where in the code? Is there some sort of guideline for this?

You can get properties for Files and Folders without the need of the file picker.
File and folder properties (Windows Runtime apps using JavaScript and HTML)
The user will need to authentic with the service as well as grant consent for your application access to their data. Other than that there would be no user interaction required.
You can also use the REST Api's directly once authenticated and granted access. The REST API's are documented here.
Using the REST API
As for the polling interval I might consider using an "observer" design pattern. You're cloud storage system component would register with the "provider" (the parent HTML application) for notifications. You could call the "sync" logic to execute when a predefined operation occurred such as login. You could persist the modified date time your applications root data folder. Then only look for changes in the event of that miss match.
Polling at a given time frequency will only ensure that the data is in sync at that specific time. The user sync state may or may not be valid when they access your application regardless of what frequency you put on the polling method.

Regarding the Dropbox API at least, this is correct. Using the Dropbox JavaScript SDK you need to poll for changes and then pull those changes into your app's local state.