I want to deactivate the any license which is already activated form License4j License Manager tool.
Lets say I deactivated the license from License4j License Manager tool. Now if I launch my application should fail to start if my license is deactivate.
But I am not able to find any API which Activation Status will show me as License is deactivated.
I used Validation API which return License object and shows Activation Successful status and activation not required.
When you deactivate the license using the manager tool, the activation is deleted on the server only, the activated license must be deleted in licensee's computer. Usually, the better approach is to call autoDeactivate method in API then delete the saved license file on the computer.
Related
I would like to restrict some functions in a user written server add-in for certain users or groups.
Question: Is it possible to get (via an API) the user name who is sending a "Tell" command from a remotely connected server console?
Example:
Tell AddinName Command (issued remotely by Hotline User)
Tell AddinName Command (issued remotely by Admin User)
The remote console (and therefore the "Tell" command) is available to both users, but a subset of commands should only be allowed to authorised users (e.g. Group in Server Document->Security).
Is the user name (entering the "Tell" command) available (e.g. in the MessageQueue)?
I know that internally in Domino there are already some restriction possible to commands issued at the console.
The session.getCommonUserName() always returns the server name (since the add-in runs in context of the server).
Thanks for any pointer or ideas.
Andy
I believe that the answer to this is no, and it would not be advisable to implement tell commands that you can't trust to all authorized administrators.
If you really do need to confirm a user identity for a command, you're going to need to use database to queue the commands. I.e., you could build an application that stores the commands in documents in a database with a restricted ACL. Your addin code can use an Extension Manager hook to monitor the database for changes and read new documents when they appear, or you could have your application use NotesSession.SendConsoleCommand to issue something like 'tell myAddIn process ' to wake up your addin and give it the noteid of the document it just created. If you need to protect against people with full access admin rights overriding the ACL, your application could digitally sign the documents and your addin could verify the signatures.
I have added RavenDB.Embedded#5.2.2 to an ASP.NET Core 5.0 application and I am attempting to configure the license without entering it into the studio GUI form. I have 2 licenses: a community and a developer -when I copy/paste either into the studio GUI it works.
I have tried:
Putting the license json into a file called license.json in the Server directory
Setting the command line arguments to include --License.Path=C:/path/to/the/license.json
Setting the License.Path key in settings.json to the path to the license
Steps 2 and 3 but with License and the text value of the license
My expectation is that when setting the license via configuration, the studio should not prompt me for a license. Perhaps my assumption is wrong about this.
Has anyone successfully configured a RavenDB embedded instance without the web form?
From the RavenDB team:
Hi,
License is only automatically activated on a non-bootstrapped server (new, empty one). It can be done e.g. like that:
EmbeddedServer.Instance.StartServer(new ServerOptions
{
CommandLineArgs = new List<string>
{
"--License.Path=D:\\temp\\lic.json"
}
});
But if you previously bootstrapped the server (e.g. created a database and there was no license in the env variables or command line args), then license will not be automatically activated. If this was done, then you can issue a POST to https://github.com/ravendb/... with the license JSON.
I have an Okuma OSP Machine Controller running Windows XP.
By default it attempts to automatically log on when the machine is turned on.
We have changed the default administrator password and now the auto-log on fails every time.
How can I turn off this feature or update the password so that it succeeds?
Machine Types Effected: Any machine with P200 or P300 control running Windows-XP
4/1/2014: Confirmed the same applies to new OSP-300 Windows 7 controls
2/1/2015: There is another (easier) way to accomplish this on Okuma controls.
This can be done using a utility in the TOOLS directory called the "Auto Logon Setting Tool". This is perfect for anyone uncomfortable with editing the registry.
Tool location:
The utility:
Just choose the user you wish to to be logged on automatically, and click the "Register auto log-on" button.
This feature is enabled from the factory to allow users to get up and running quickly while still having the machine password protected. Because it is recommended to change the default password this is most likely a very common situation.
The automatic login behavior can be changed by editing registry settings.
Click Start, type "regedit" (sans-quotes) in the run box, and press enter.
In the folder structure in the left pane, navigate to the following folder:
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
To turn the feature OFF, change the key value of "AutoAdminLogon" to '0'
Similarly, the default user name and password can be changed by editing the appropriate keys to restore the functionality of the auto login feature.
Reference Microsoft Support article here.
The release notes for NuGet 1.5 state
NuGet now supports connecting to private repositories that require basic
or NTLM authentication.
However, the link contained in there simply leads to the hosting your own nuget feeds page, without any further mention of how to set up authentication.
I would like to set up a NuGet server that is accessible via https from the internet, but only allows people who can successfully authenticate to view or download the packages on the server.
I did create an application without auth as described in the Creating Remote Feeds section in the documentation, and it works nicely on the intranet. What do I have to do to enable authentication on this repo?
An additional requirement would be that solution should not cost hundreds of dollars (the first two answers promote products that might solve the problem but cost a lot).
This can be done by enabling Windows Authentication on the Web Site and adding credentials on the build server via the Sources command-line option, by default the credentials are stored using a DPAPI key restricted to the current user on the current machine (thus, for a build server, you would need to add credentials while logged in under the service account.)
For Developer workstations you only need to add the feed in NuGet Package Manager and then input/store credentials when refreshing the feed (you should be prompted.)
Step 1 - Require Authentication on NuGet Server (IIS Configuration)
You need to make sure the authentication module you wish to use is installed for IIS, for NTLM auth you will need the Windows Authentication module. Once installed you can open IIS Manager and drill down to your website, open the Authentication settings and Enable Windows Authentication, be sure to disable any authentication modules you do not want to support (such as Anonymous, Basic, etc.)
To ensure that user credentials are used, right-click on the Site and select "Advanced Settings", then click on the button for "Physical Path Credentials". In the dialog ensure that "Application User (pass-through authentication)" is selected.
More detailed information about standard IIS configuration for Windows Authentication can be found on TechNet including configuring from a command-line and enabling Negotiate (if that was your goal.)
Step 2 - Add Sources to NuGet Config (Build Server, Publishers)
nuget.exe sources add -Name "Fabrikam Feed" -Source "https://nuget.fabrikam.com:443/nuget/"
nuget.exe sources add -Name "Fabirkam Publish" -Source "https://nuget.fabirkam.com:443/"
Here we are adding two entries, one which will be used as the normal, authenticated Feed URL (for fetching packages from the server.) The second will be used for publishing to the server (adding or updating nupkg files.)
Step 3 - Update Credentials for Added Sources (Build Server, Publishers)
nuget.exe sources update -Name "Fabrikam Feed" -Source "https://nuget.fabrikam.com:443/nuget/" -UserName "Developer" -Password "g0d"
nuget.exe sources update -Name "Fabrikam Publish" -Source "https://nuget.fabrikam.com:443/" -UserName "Developer" -Password "g0d"
Here we have added credentials to the config, if you view %APPDATA%\NuGet\NuGet.config you should see the feeds you have added as well as encrypted credentials.
If you do not have the ability to log in as the server it is possible to store credentials in clear text by utilizing the StorePasswordInClearText option, but this is not advised in a shared environment.
Step 4 - (Optional) Disable the Publish URL in Visual Studio (Developers)
Open Visual Studio and navigate to the NuGet Package Manager Settings Dialog, untick the "Fabrikam Publish" feed. This will not affect your ability to publish, however, if you do not disable this feed you will receive errors when you try and refresh packages for "All" sources (as it is a publish URL, not a feed URL.)
Step 5 - (Optional) Store Windows Credentials in Visual Studio (Developers)
Open Visual Studio and navigate to the NuGet Package Manager, click on "Fabrikam Feed". You should be prompted for credentials. You can enter credentials here and tick the save/remember options. This ensures that attempting to refresh the feed in Visual Studio doesn't constantly ask for credentials. In the latest releases of NuGet Package Manager the feed is fetched using a standard HTTP request and the credentials you've stored to nuget.config are NOT used.
Notes:
You do not need a third party solution to host private, secure feeds. NuGet server is freely available and NTLM/AD/Windows security is supported by both IIS and NuGet tooling.
Developers who do not need to publish to the feed do not need to store credentials in their config. They also do not need a 'Publish' feed configured. This is only necessary for build servers or other publishers (re: Steps 2 and 3.)
All developers who will use the package feed will be interested in Step 5, this should be all that is required for most developers. They can simply add the feed from within Visual Studio, then enter their credentials when prompted.
If credentials change you can navigate to Start -> Manage Windows Credentials and delete "VSCredentials_nuget.fabrikam.com".
Step 2 can be performed in visual studio, but for clarity I've given the command-line here. Step 3, however, must be performed via command-line (or using the NuGet APIs.)
In a future release of NuGet rumor is credential information can be stored at the solution or project level (details are unclear), this is likely only of interest to people in a multi-tenant build environment where they do not have access to the build server.
Hope this helps someone else out there!
The solution I actually chose was to use TeamCity as NuGet server; while it's a bit of a hassle to set up because it lacks nuget push functionality, it now works nicely and at no additional cost serving NuGet packages to authenticated users only.
I am using Wix to install a windows service. The service will need to run under a non system/service account that is set up by the user.
Is it possible to have it prompt for the username/password for the service login?
The Community MSI Extensions on GitHub contains a ServiceCredDlg dialog for prompting username and password. According to the docs, it can test the credentials are valid and that user has 'logon as a service' rights.
Yes, but it's not built-in. You can setup a GUI in WiX (which is not too intuitive) where you can prompt for any setting you'll need in later steps.
First, check out how to create a GUI that sets custom properties by following these guidelines, ensuring that your GUI fills properties SERVICEACCOUNT and SERVICEPASSWORD. Then use the ServiceInstall element with those properties as shown here.
WiX doesn't (or at least didn't) have anything nice out of the box for what you are looking for. Best option that I am aware of is to roll-your-own.
https://www.geekproject.com/post/wix-service-account-dialog/
You can set PUBLIC PROPERTIES (uppercase) with the credentials on the command line and use these to install the service.
msiexec.exe /I "setup.msi" /QN USER="username" PASS="password"
A custom action can also be used to retrieve these values from the user during an interactive install, but if you do this remember to make the display of the message obey the setups UILevel value. Showing a message box from a custom action in a silent install is considered a serious setup error:
INSTALLUILEVEL_NONE 2 Completely silent installation.
INSTALLUILEVEL_BASIC 3 Simple progress and error handling.
INSTALLUILEVEL_REDUCED 4 Authored UI, wizard dialogs suppressed.
INSTALLUILEVEL_FULL 5 Authored UI with wizards, progress, errors.
Perhaps the best option is to show the dialog in an interactive install, and refuse to install silently if these properties aren't set on the command line. This is a simple custom action to test the values of the USER and PASS properties.
And obviously it is not recommended to use user accounts to run services.