Say I have a BrowserWindow set up with the following options:
{
webPreferences:{
partition: 'persist:example'
}
}
I am also making a call to app.setPath to set userData to a local directory.
If I open my Electron application and log in, close the application, then open a new instance, I am still logged in. This is expected session behavior.
However, if I open my Electron application and log in, then open a second instance of my application with the same BrowserWindow settings and same application paths, the second instance will not be logged in, despite being propped up to use the same user data and partition.
Shouldn't the second instance be able to use session information from the first instance without closing the first instance? What am I doing wrong?
Related
We have an electron app that we're setting up to launch from protocol links following the structure described here: https://github.com/oikonomopo/electron-deep-linking-mac-win (found from Open app and pass parameters with deep linking using Electron (macOS))
Once the app is installed, we either open the app from finder/launchpad or can invoke the app from a browser using myapp://someparams.
If I invoke myapp://someparams when the app is closed, the app opens and the main process fires the open-url event for mac as expected and I can grab the parameters from the url. If the app was initially opened via this method, re-invoking the myapp://someparams continues to focus the app and fire open-url as expected.
However, if the app was initially opened from the finder, launchpad, or command line, invoking myapp://someparams causes the second-instance event to fire instead and I haven't been able to find a way to get the url that was used to invoke the app. Windows works as expected since the second parameter to the second-instance event contains the protocol as a parameter but that isn't the case with mac.
So the question is - is there a way to grab the protocol/url from the second-instance event on mac? Or is there another way around this?
I did see this snippet from the docs: https://electronjs.org/docs/api/app#apprequestsingleinstancelock
On macOS, the system enforces single instance automatically when users try to open a second instance of your app in Finder, and the open-file and open-url events will be emitted for that. However when users start your app in command line, the system's single instance mechanism will be bypassed, and you have to use this method to ensure single instance.
You should set LSMultipleInstancesProhibited to true in info.plist.
If you are using electron builder, you can set 'LSMultipleInstancesProhibited: true' at mac.extendInfo
For example
mac: {
...
extendInfo: {
LSMultipleInstancesProhibited: true,
}
}
I'm making a sandboxed Mac app, and I used NSOpenPanel to get a file URL, and saved it to UserDefaults as a security-scoped bookmark. When I quit and restart the app, I can resolve that blob of Data into a URL again.
The documentation says I should call startAccessingSecurityScopedResource(), and check its return value. (That does return true when I call it.) But if I don't call that, I've still got a resolved URL, and I still appear to have permissions to access it.
What does startAccessingSecurityScopedResource() actually do? Is there anything bad that can happen, if I don't call it?
As long as your app only accesses files in standard locations (Downloads, Music
Movies, Pictures) and you included the required entitlements for programmatic file and folder access in your app, you don't need to store security scoped bookmarks for those locations.
But for other locations that should remain accessible after the app has been restarted, you should store security scoped bookmarks and call startAccessingSecurityScopedResource() before access. If you skip that step, you'll get an exception as soon as you try to access that file.
startAccessingSecurityScopedResource() makes the security scoped bookmark's resource available to your app's sandbox thus granting you access to that resource.
I'm writting remote login app and I want to include the possibility to start new GUI session for different user. Goal is similar to what is done on Screen Sharing.app when user (different than already logged in) is connected - he can create new desktop without messing with session currently displayed. Is there an API for this? Maybe could You give me some useful links? I can't find anything to point me to the right direction so far.
Edit:
I am already able to connect to running "background" GUI sessions. Now I want to have a possibility to create session for user which is not logged in yet.
Edit: Spawning loginwindow under WindowServer process will also do the trick. When only one user is logged in, loginwindow process is terminated. Additionally - maybe there's a possibility to prevent loginwindow termination?
Edit:
I've tracked down function from private API which executes new loginwindow process under WindowServer and it works OK. Function is called CGSCreateLoginSessionWithDataAndVisibility, the problem is - this is private function I don't know what parameters it takes. Now I call it like this:
CGSSessionID outSession = 1;
CGSCreateLoginSessionWithDataAndVisibility(&outSession, NULL, false);
Does anyone know what arguments are used in CGSCreateLoginSessionWithDataAndVisibility or is there another way to achieve what I want?
Short of reverse engineering fast user switching and some hackage, I'm not too sure this could be accomplished. AFAIK there are not any public APIs other than some notifications and session states that can be observed for when the user switches users. Some info here on how to observe those notifications (you can do it through Cocoa or Carbon) and how to fetch the current sessions information.
Hope this helps, sorry for not being more helpful!
I have created an asp.net application in which i have used global.asax. I have created a static class which stores user information such as LoginID, CompanyID etc using properties. A property IsLoggedIn indicates whether user logged in or not. I have created a method ResetAll() within the same class to reset those properties.
The problem is that if the user directly closes the browser window without logging off the property values are not resetted. Therefore if the user opens a new browser window, the user is logged in automatically. I have also called ResetAll() within from Session_End() but still it is not working. Could someone explain me whats wrong with that or simply how to reset the property values if the user directly closes the browser window.
If I am reading this correctly and you have a class with static members, then you are going to run into issues. With an ASP.NET web app, static members are static for the entire AppDomain, not just for an individual user, so the values would be the same no matter where the request has come from.
It sounds like what you really need to think about doing is storing an instance of the user information class in the session. That way the information is specific to that particular user. Also, that should solve your issue as the session cookie is normally removed when the browser window is closed, forcing a new session when the browser window is re-opened.
So something like:
Dim thisUser As New UserInformation()
thisUser.LoginID = someValue
Session("UserInformation") = thisUser
You cannot make the class static. Worse than keeping the user logged in across sessions is the fact you cannot have multiple users in your system. They will all share the same login information. You should read about static.
What you want is to store an instance of that class in the session and access it whenever you need.
If I open a connection to the server from firefox browser, and then I open a new tab within the same instance of browser to make a connection to the server, is it considered one session to server or considered as two diff sessions?
It's the same session (you can easily test this out yourself).
It seems to be the same session.
However, if I use diff user to login, both seems to be categorized under same session? Is this the correct behaviour?
If you click a link on the current session to open it up in a new tab, then it'sthe same session. If you just open up a blank window and log in again, then, to the best of my knowledge,it's a new session.