In a node.js cli app running on a windows machine, you can get the current local user using:
// method 1
const os = require('os')
console.log(os.userInfo())
// method 2
console.log(`${process.env.USERDOMAIN}\\${process.env.USERNAME}`)
Which outputs:
# METHOD 1
{
uid: -1,
gid: -1,
username: 'adam',
homedir: 'C:\\Users\\adam',
shell: null
}
# METHOD 2
MYPC\adam
However, in modern Windows OS (e.g. Windows 10, 11), many users opt to sign-in with a Microsoft account. Apparently, this means there are 2 mirrored accounts on the machine:
{USERDOMAIN}\{USERNAME} where USERDOMAIN could be the local machine name or the enterprise network domain name
MicrosoftAccount\{EmailAddress} where EmailAddress is the Microsoft account username
How can I retrieve the 2nd variant of the username in node.js?
IMHO, you can use the windows registry hive HCU, which maps to the current user hive and find the data you need somewhere in the hive, though I don't know the exact path.
Alternatively, you could try running some PS1 script/command that will get this information for you, but this method cannot be reliable, since this option (running ps1) may be disabled on some machines by the user.
And last but not least, you can always build a native Node.js extension, using C++ and access the native Windows API to do what you want :)
Related
I am working with Electron and Node.js. We have developed an application that works fine on windows and as a requirement had to package it for mac os. I packaged the application using electron-packager, the packaging process completes and package is generated. Double clicking it throws an error that permission denied for mkdir, as i am using node localstorage to maintain some settings on the user's local machine. somehow mac doesn't local storage to create folder in the root of the application. Any help in this matter will be great. Thanks
First off, is the code in question in the main process or in a renderer process? If it is the latter, you don't need to use 'node-localstorage', because you can use the renderer's native LocalStorage. If you are in the main process, then you need to provide your own storage strategy so using 'node-localstorage' is a viable option.
In any case, you need to carefully consider where to store the data; for starters, let's look at where Electron's renderer processes would store its LocalStorage data: this differs based on the OS, but you can get and set the paths using the app module -- the path in question is userData, which on OS X would default to ~/Library/Application Support/<App Name>. Electron uses that folder to persist cookies, caches, LocalStorage etc. so I would suggest using that folder as well. (Otherwise, refer to XDG defaults for good defaults)
What your example above was trying to do is store your 'errorLogDb' in the current working directory, which might depend on your OS, where your App is installed, how you executed it, etc.
Finally, it's a good idea to differentiate between your 'production' app and your app during development and testing, because you might not want to use the same storage folders for every environment. In any case, just writing to './errorLogDb' is likely to cause lots of headaches so I'd be thankful for the permission denied error.
this strategy worked for me:
const { LocalStorage } = require('node-localstorage');
let ls;
mb.on('ready', () => {
let prefsPath = mb.app.getPath('userData') + '/prefs';
ls = new LocalStorage(prefsPath);
loadPrefs();
});
mb.on('after-create-window', () => { /* ls... */ }
exports.togglePref = () => { /* ls... */ }
I'm using mongodb on 64Bit and 32Bit Linux servers with same configuration, where the option auth=true is set in both config files.
While the 64Bit system required an authentication to run commands like show users or show collections, the 32Bit version gives you all the requested informations without running db.auth() before.
It looks like, the 32 Bit version ignores the auth=true option at the config file.
So: how can I enable auth for mongodb running on an 32Bit system?
The 32bit version should support authentication just fine. But it is possible that:
It uses a different configuration file (use: -f /etc/mongodb.conf as option when starting MongoDB) or you can specify --auth on the command line
Because the databases are empty and no user is setup at all, authentication is not required. As soon as you add a user, it will then require db.auth().
You don't have a user on the admin database defined. Without this, you can always connect on localhost.
The point is, that authentication is disabled because there is no db users added, only users for a specific database. Connecting to this database using localhost results in an "auth"-free environment. (see for this also the answer from #Derick which point to a possible reason.)
To come back to the question:
So: how can I enable auth for mongodb running on an 32Bit system?
The point is: the auth is active, but not for connects from localhost. To enable auth for connects from localhost, the following startup option is needed:
enableLocalhostAuthBypass=0
I finished this,the role is necessary
db.createUser(
{
user: "youloginname",
pwd: "123456",
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)
I have a need to write a .NET application which will query Active Directory while running in Windows PE on a computer which is not yet a member of the domain.
We are running this during a Microsoft Deployment Toolkit task sequence (note that MDT 2012 has been configured to load support for .NET into the WinPE environment - the .NET application is starting without any problems).
I am using the code below to bind to the domain:
DirectoryEntry entry = new DirectoryEntry(
path,
username,
password,
AuthenticationTypes.ServerBind | AuthenticationTypes.Secure);
I have tried a path both of the form:
LDAP://domainServer/dc=domain,dc=name
And also without a domain controller name as
LDAP://dc=domain,dc=name
I have also tried using a username both of the form domain\username and also just username.
The DirectoryEntry object seems to be constructed okay, but when I try to execute Console.Writeline(entry.Name) to confirm a valid connection has been made, I get the following exception:
System.Runtime.InteropServices.COMException (0x80005000): Unknown
error (0x80005000) at
System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind() at
System.DirectoryServices.DirectoryEntry.get_Name()
I have tried other variations on this code, trying to execute LDAP queries with various filters, trying to rewrite it in VBScript, etc... but the code posted above is the simplest example I could come up with which reproduces the problem.
From what I have read, in a scenario like this you would always need to use AuthenticationTypes.ServerBind and that is why I am trying to specify the code within the ADSI LDAP path. But what is wrong with the code above? To me, it looks like it is passing all needed information in the parameters to the DirectoryEntry constructor.
There is a way to get it work, but it's not supported by Microsoft. This post helped me a lot. It works, tested and approved for a deployment of new computers :)
Get the ADSIxXX.inf from the zip file to C:\ADSI
Copy the following files from a Windows/System32 to C:\ADSI. Carefull of Architecture
x86 x64 -
adsldp.dll
adsmsext.dll
adsnt.dll
mscoree.dll
mscorier.dll
mscories.dll
Mount the bootimage.wim
No need to load Package (Your WinPE is already configured to load .NET API), juste add ADSI driver:
Dism /Image:C:\Mount /Add-Driver /Driver:C:\ADSI\ADSIxXX.inf /forceunsigned
No need to load his script
Unmount the bootimage.wim
Then it's done, if your .NET application is well implement ;)
I'm not sur the PIPE | is supported as an argument too, just set to AuthenticationTypes.Secure -
DirectoryEntry entry = new DirectoryEntry(
path,
username,
password,
AuthenticationTypes.ServerBind | AuthenticationTypes.Secure);
Link: http://www.deploymentresearch.com/Research/tabid/62/EntryId/74/ADSI-plugin-for-WinPE-4-0.aspx#AddComment
I'm working on a project where I'm trying to implement authentication against external user base for customers, this seems to be working correctly.
Recently there has been added another requirement that some people (not present in the aforementioned base) need to be able to edit parts of pages' content. First thing that comes to mind is to have separate ORM/File Auth driver enabled for those few editors to be able to authenticate them separately.
Is it possible to use two Auth drivers at the same time in Kohana 3.2?
Yes, you can use different drivers at once. Just create another instance instead of standard singleton:
// default Auth
$config = Kohana::$config->load('auth');
$auth = new Auth($config);
$user = $auth->get_user();
// special Auth for administration
$config2 = Kohana::$config->load('admin_auth');
$auth2 = new Auth($config2);
$admin = $auth2->get_user();
Restrictions:
You must use differ configs (driver and session_key values must differ). Note that some settings are defined in classes and cant be changed by config (for example, "remember" cookie named authautologin).
You cant share default ORM models (Model_User, Model_Token, Model_Role), because their names are hardcoded. But ORM driver & File driver can be used.
Kohana's Auth module does not natively support using two Drivers.
However, you can implement a new Driver yourself very easily. You can follow the instructions for creating a new Driver by copying the existing driver and modifying it, here: http://kohanaframework.org/3.3/guide/auth/driver/develop
The simple thing to do would be to put the following logic in your _login method:
Check the external user database for a valid login
If there is a valid user in the external user database, return true.
If there is no valid user in the external user database, check the local user database instead.
If the user exists in the local database, return true.
I'm looking for a way to query the Terminal Services Home Folder property of user objects in Active Directory. My goal is to be able to perform a reverse lookup, finding the user(s) that use a particular home folder.
Normally to perform a search I would do something like this:
using (var search = new DirectorySearcher())
{
// Find a user based on their telephone number
search.Filter = "(telephoneNumber=999)";
search.PropertiesToLoad.Add("displayName");
var result = search.FindOne();
if(result != null) {....}
}
But the Terminal Services settings don't seem to have a referable LDAP attribute name - in the past to set these values I've had to use the IADsTSUserEx interface with an existing DirectoryEntry to manipulate the TS profile and home folder properties. However this is only useful when I have the user account in question - it's not very practical to step through every user in a domain and create a DirectoryEntry object for them just to check their TS profile path.
Is there any practical way to perform a "WHERE User.TerminalServicesProfilePath=X" query in .NET?
Nobody here so, I try an explanation.
In Windows Server 2008 (and R2), the Terminal Services Terminal Server Runtime Interface takes the user parameters from the user Active-Directory attribute called userParameters. As explain in Microsoft documentation userParameter contains Terminal Server parameter as blob.