Will the application automatically detect which environment that it is in or do you need to tell it?
The API is the same for both client and server side modes. To initialize your application for server side mode, you initialize your TTAPIOptions instance as follows:
// Add your app secret Key here. It looks like: 00000000-0000-0000-0000-000000000000:00000000-0000-0000-0000-000000000000
string appSecretKey = “Your App Key”;
//Set the environment the app needs to run in here
tt_net_sdk.ServiceEnvironment environment = tt_net_sdk.ServiceEnvironment.UatCert;
tt_net_sdk.TTAPIOptions apiConfig = new tt_net_sdk.TTAPIOptions(
tt_net_sdk.TTAPIOptions.SDKMode.Server,
environment,
appSecretKey,
5000);
Related
I have earlier achieved this .net 3.1. But it couldn't be possible with .Net 6 because of startup.cs removed.
I have registered a few services,
builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
var appSettings = builder.Configuration.GetSection("AppSettings").Get<AppSettings>();
builder.Services.AddScoped<IEncryption, Encryption>();
//Here I need to get the IEncryption Service, and call the method in this service to encrypt/decrypt the connection string to pass to DBContext Service.
builder.Services.AddDbContext<CatalogDbContext>(options => options.UseNpgsql(
appSettings.ConnectionString));
var app = builder.Build();
Earlier in .NET 3.1, I used BuildServicProvider() to get the Encryption service, and call the methods in that service to do the required logic then got the proper connection string I wanted that would be passed to the DBContext service on the next line.
Now, .NET 6/7 is forced to use the services only after app = builder.Build(); so, I can't register the DBCOntext after the build() method.
How can I solve this case? Any recommended approach to do this in .NET 6/7?
You still can useStartup.cs in .net 6
var builder = WebApplication.CreateBuilder(args);
var startup = new Startup(builder.Configuration);
startup.ConfigureServices(builder.Services); // calling ConfigureServices method
var app = builder.Build();
startup.Configure(app, builder.Environment); // calling Configure method
And then you can use ConfigureServices and Configure methods to register your services before building.
You didn't need to use BuildServiceProvider in .NET Core 3.1 either. AddDbContext has an overload that provides access to an IServiceProvider instance :
builder.Services.AddDbContext<CatalogDbContext>((services,options) =>{
var myOwnDecrypter=services.GetRequiredService<IMyOwnDecrypter>();
var cns=myOwnDecrypter.Decrypt(appSettings.ConnectionString,key);
options.UseNpgsql(cns);
});
or, if you use the ASP.NET Core Data Protection package :
builder.Services.AddDataProtection();
...
builder.Services.AddDbContext<CatalogDbContext>((services,options) =>{
var protector = services.GetDataProtector("Contoso.Example.v2");
var cns=protector.Unprotect(appSettings.ConnectionString);
options.UseNpgsql(cns);
});
or, if IConfiguration.GetConnectionString is used :
builder.Services.AddDataProtection();
...
builder.Services.AddDbContext<CatalogDbContext>((services,options) =>{
var conn_string=services.GetService<IConfiguration>()
.GetConnectionString("MyConnectionString");
var protector = services.GetDataProtector("Contoso.Example.v2");
var cns=protector.Unprotect(conn_string);
options.UseNpgsql(cns);
});
That said, it's the configuration provider's job to decrypt encrypted settings, not the service/context's. ASP.NET Core's configuration allows using multiple different configuration sources in the same host, not just a single settings file. There's nothing special about appsettings.json. That's just the default settings file name.
You can add another settings file with sensitive contents with AddJsonSettings. That file could use the file system's encryption, eg NTFS Encryption, to ensure it's only readable by the web app account
You can read settings from a key management service, like Hashicorp, Azure Key Vault, Amazon Key Management etc.
You can create your own provider that decrypts its input. The answers to this SO questino show how to do this and one of them inherits from JsonConfigurationProvider directly.
Important Caveat: In general, my suggestion below is a bad practice
Do not call BuildServiceProvider
Why is bad? Calling BuildServiceProvider from application code results in more than one copy of singleton services being created which might result in incorrect application behavior.
Justification: I think it is safe to call BuildServiceProvider as long as you haven't registered any singletons before calling it. Admittedly not ideal, but it should work.
You can still callBuildServiceProvider() in .Net6:
builder.Services.AddScoped<IEncryption, Encryption>();
// create service provider
var provider = builder.Services.BuildServiceProvider();
var encryption = scope.ServiceProvider.GetService<IEncryptionService>();
// use service here
or alternatively
builder.Services.AddScoped<IEncryption, Encryption>();
var provider = builder.Services.BuildServiceProvider();
using (var scope = provider.CreateScope()) {
var encryption = scope.ServiceProvider.GetService<IEncryptionService>();
// use service here
}
Alternative:
You can still use the classic startup structure in .Net6/7. We upgraded our .Net3.1 projects to .Net6 without having to rewrite/restructure the Startup()
When i set proxy settings in the system my Electron application gets it automatically for common requests (axios package), but not for websockets (socket.io-client package). If i provide proxy settings manually then websockets starts to work too, but i want to try to avoid manual configuration, because it may be tricky to the real app's users. So i'm looking any way to get proxy settings from electron and transfer them to the websockets.
I have tried to use login event for my browserWindow in the both main and renderer process, but it doesn't trigger at all. Is there any way to get proxy settings that electron uses?
I've found the solution. It's possible to take proxy-settings inside the main process.
mainWindow = new BrowserWindow({})
const ses = mainWindow.webContents.session;
ses.resolveProxy('url_you_need_to_achieve', (proxy) => {
// do whatever you want with proxy string, that contains proxy-setting
});
We have a ColdFusion 8 application running in JRun4 on Windows Server 2003.
How do we detect (& display) whether the debugger is running with Allow Line Debugging enabled in CF Administrator. After detecting, we want to display a warning on the application that the debugger is running.
You should be able to use the ColdFusion Administrator API for this. Of course you will need the security/permissions in order to use this. If you are using sandbox security, enable access to the cf_web_root/CFIDE/adminapi directory to use the Administrator API. Basically the Administrator API gives you programmatic access to most of the ColdFusion Administrator settings.
From the documentation:
You can use the Administrator API to perform most ColdFusion Administrator tasks programmatically. The Administrator API consists of a set of ColdFusion components (CFCs) that contain methods you call to perform Administrator tasks.
The CFC for managing the debug settings is debugging.cfc.
Here is some pseudo code (this has not been tested):
<cfscript>
// Instantiate the administrator.cfc
adminObj = createObject("component","cfide.adminapi.administrator");
// Call the administrator.cfc login method, passing the ColdFusion Administrator password
adminObj.login("#password#","#username#");
// Instantiate the debugging CFC
debugObj = createObject("component","cfide.adminapi.debugging");
// Call the desired CFC method
if (debugObj.isLineDebuggerEnabled()) {
if (debugObj.isLineDebuggerRunning()) {
// Stop line debugger
debugObj.stopLineDebugger();
}
// Disable the line debugger
debugObj.setLineDebuggerEnabled(enabled="false");
}
</cfscript>
That should get you started. Here is some documentation on the debugging.cfc and it's methods.
Manages debug settings.
hierarchy: WEB-INF.cftags.component
CFIDE.adminapi.base
CFIDE.adminapi.debugging
path: {web-root}\CFIDE\adminapi\debugging.cfc
serializable: Yes
properties:
methods: addDebugEvent,
deleteIP,
getCurrentIP,
getDebugProperty,
getDebugRecordset,
getIPList,
getLineDebuggerPort,
getLogProperty,
getMaxDebuggingSessions,
isLineDebuggerEnabled,
isLineDebuggerRunning,
restartLineDebugger,
setDebugProperty,
setIP,
setLineDebuggerEnabled,
setLineDebuggerPort,
setLogProperty,
setMaxDebuggingSessions,
startLineDebugger,
stopLineDebugger,
validateIP*
inherited methods: dump,
getEdition,
getInstallType,
getJRunRootDir,
isAdminUser,
RDSInvoker,
setJrunSN
I'm testing out deploying my own parse server following the steps in the Parse Server Guide. I've got the server up and running and have been able to create and fetch objects via curl. I built a simple iOS app using the Parse SDK (1.14.2). I've initialized the SDK with the app id and server url as described in the Parse Server Guide. When I try to make requests, I get back unauthorized from the server. Digging further, I noticed that the SDK is not sending the application id header to the server. I modified the SDK to send the application id header and everything works. Am I missing a configuration step somewhere?
This is because you are not passing the ClientKey. In swift 3 you would pass it like this in the didFinishLaunchingWithOptions.
// Init Parse
let configuration = ParseClientConfiguration {
$0.applicationId = PARSE_APP_KEY
$0.clientKey = PARSE_CLIENT_KEY
$0.server = PARSE_SERVER_URL
$0.isLocalDatastoreEnabled = true
}
Parse.initialize(with: configuration)
If you are falling when trying to test CloudCode, then its because your parse-server is not passing the Javascript key. So just make sure you initialize the server to do so if this issue is related to Parse.Cloud function.
I've been tasked with converting a legacy application to mvc. The app used pgp.exe to pgp sign user input and send it as an email. The application works locally and on a test server but won't run on a live server. I've had to jump though hoops such as running a specified user in the application pool so that we can set the keys in the users profile BUT it worked.
For some reason on the live server which is windows 2003 IIS 6 and identical to the testing server it fails. The problem is pgp.exe just wont seem to sign and create files the message I get from the console out put is. "Signature Error"?? When I put the command into a shell window logged in as the app pool user it runs no problem (after a fight with some permissions) but when running through the mvc application/IIS server it fails. The code used to call the process is below.
var startInfo = new ProcessStartInfo();
startInfo.FileName = _pgpexeLocation;
//startInfo.FileName = "pgp.exe";
startInfo.Arguments = string.Format("-sta \"{0}\" -u keyuser-z keypass +COMPATIBLE +FORCE", _tempFilePath);
startInfo.UseShellExecute = false;
startInfo.RedirectStandardOutput = true;
startInfo.LoadUserProfile = true;
using (Process exeProcess = Process.Start(startInfo))
{
// TODO: set limit to wait for and deal with exit
exeProcess.WaitForExit();
//var stringItem = exeProcess.StandardOutput.ReadToEnd();
//Logger.Info(stringItem);
}
I'm clutching at straws here hoping somebody has done something similar before and can help. I'm guessing it's key location or file location not being picked up somewhere but not sure what else to try?
Turns out that even though the app pool was using a specific user and I'd set the keys up in that users appdata folder when I checked the underlying process call it was actually trying to pick the keys up from the Default User profile. Not sure if this was an IIS config or something similar but moving the keys and pgp folder to this appdata instead worked?