I just upgraded from Cordova (PhoneGap) 1.5 to 1.9 today and suddenly my FileTransfer params stopped posting. I can tell because I have the server side debugging the $_POST parameters, and they are now blank. Here is the code being run:
var options = new FileUploadOptions();
options.fileKey="file";
options.fileName=imageURI.substr(imageURI.lastIndexOf('/')+1);
options.mimeType="image/jpeg";
options.chunkedMode=false;
var params = new Object();
params.client_token = "This will not make it across, sadly...";
options.params = params;
var ft = new FileTransfer();
rs = ft.upload(imageURI, "http://www.mysite.com/api/uploadimage",
function() { alert('Yay!'); },
function() { alert('Fail happens..'); }, options, true);
Has this happened to anyone else? Maybe there's a new setting that has to be set?
UPDATE:
Just to make sure it wasn't CodeIgniter causing server side issues, I now have the above code posting to echo.php, which simply does "print var_dump($_REQUEST);". Still no results. I was able to cheat and throw the client token on the URL as a $_GET parameter, but it seems a shame to hack the server side because the client side changed.
I had the same issue with the iOS Cordova 1.9. I found and fixed the bug in the framework code, you can download my fork of Cordova and use the newly patched /dist/Cordova-1.9.0.dmg from it: https://github.com/eschultz/incubator-cordova-ios/
At a quick glance the Android Cordova 1.9 code looked fine. I submitted my changes to Apache to include the fix in their next release.
Hope this helps.
Related
I have tried this code to generate the token:
public async Task Authenticate() {
MultipartFormDataContent content = new MultipartFormDataContent();
content.Add(new StringContent(_clientId), "client_id");
content.Add(new StringContent(_clientSecret), "client_secret");
content.Add(new StringContent("client_credentials"), "grant_type");
content.Add(new StringContent(".default"), "scope");
try {
var task = _client.PostAsync(new Uri(string.Format("https://login.microsoftonline.com/{0}/oauth2/v2.0/token", _tenantId)), content);
var res = task.GetAwaiter().GetResult();
if (res.StatusCode == System.Net.HttpStatusCode.OK) {
JsonDocument resJSON = await JsonDocument.ParseAsync(await res.Content.ReadAsStreamAsync());
_accessToken = resJSON.RootElement.GetProperty("access_token").GetString();
lock(this) {
_expiresAt = DateTime.UtcNow.AddSeconds(resJSON.RootElement.GetProperty("expires_in").GetInt16());
}
} else
throw new Exception(res.ReasonPhrase);
} catch (WebException ex) {
// handle web exception
}
}
But I got the error like
error_description=AADSTS1002016: You are using TLS version 1.0, 1.1 and/or 3DES cipher which are deprecated to improve the security posture of Azure AD. Your TenantID is: 334xxxx. Please refer to https://go.microsoft.com/fwlink/?linkid=2161187 and conduct needed actions to remediate the issue. For further questions, please contact your administrator.
Trace ID: c8a502xxxx
Correlation ID: 325a1dxxxxx
Timestamp: 2022-08-04 13:35:23Z
But the same code works in console application.While using this code inside the dll it throws the exception.All the versions are same - .net framework,System.text.json,system.memory etc.
Please help me to sort out this.
According to this page the default TLS version that is used, depends on the targeted .net version and the used operating system.
Targeting .net framework 4.8 should default to TLS1.2 on Windows 10/11
Any change that you are using an older version of either? Or that you are setting the tls version explicitly somewhere in your application?
Also using lock inside an asynchronous method is bad practice and might deadlock your code.
When I use .NET Framework 4.6.1, I encounter the same problem. After I switched the version to 4.7.2, the problem was not solved until I explicitly specified the version in Web.config.
<httpRuntime targetFramework="4.7.2" />
In .net core 3.1 Blazor App, my Instrument Key is always null.
I added the follwing package
Microsoft.ApplicationInsights.AspNetCore 2.14.0-beta5
in startup.cs, i am adding the following line
services.AddApplicationInsightsTelemetry();
i even tried hardcoding the instrument key via options but no luck there either.
Microsoft.ApplicationInsights.AspNetCore.Extensions.ApplicationInsightsServiceOptions aiOptions
= new Microsoft.ApplicationInsights.AspNetCore.Extensions.ApplicationInsightsServiceOptions();
aiOptions.InstrumentationKey = Configuration.GetSection("ApplicationInsights:InstrumentationKey").Value;
services.AddApplicationInsightsTelemetry(options);
in appsetting.json, i have defined the applicaiton Insight
"ApplicationInsights": {
"InstrumentationKey": "XXXXXXX-4f59-4580-a96a-XXXXXXX"
}
In my Blazor Page i am inject the dependency
#inject Microsoft.ApplicationInsights.TelemetryClient telemetryClient;
now when i search for telemetryClient.InstrumentationKey it is empty.
What am i missing ?
It's weird. I tried to view the key by calling telemetryClient.InstrumentationKey as well, but like you said it's empty. But when I try to track something with .TrackEvent, it logs.
For example;
_telemetryClient.TrackEvent("BlazorAppSampleEvent", new Dictionary<string, string>() { { "Hello from", "Blazor App" } });
Sounds interesting to me, I will have a couple of minutes more and update here if I get something new.
BTW, just so you know, Microsoft.ApplicationInsights.AspNetCore 2.14.0 is publicly available, so you can upgrade it from beta-5 to public one.
https://www.nuget.org/packages/Microsoft.ApplicationInsights.AspNetCore/2.14.0/
This is an old issue.
TelemetryClient.InstrumentationKey or TelemetryClient.Context.InstrumentationKey should be empty unless you explicitly set it there as an override of what is in configuration.
As mentioned above, explicitly set it like: TelemetryClient client = new TelemetryClient() { InstrumentationKey= "your_ikey" };, then you can see the key via TelemetryClient.InstrumentationKey or TelemetryClient.Context.InstrumentationKey.
Note: this issue does not break the functionality of application insights.
I have upgraded my project to asp.net core v2.2 from v2.1 and everything was used to work just fine.In the code shown below, I am trying to initilaize an RSA Key for with IdentityServer4(v2.3.2) and while trying to get a token I get the following error.
try
{
var rsaProvider = new RSACryptoServiceProvider(2048);
var rsaParametersPrivate =
RsaExtensions.RsaParametersFromXmlFile(Configuration.GetSection("JwtSettings:rsaPrivateKeyXml")
.Value);
rsaProvider.ImportParameters(rsaParametersPrivate);
var securityKey = new RsaSecurityKey(rsaProvider);
_signingCredentials = new SigningCredentials(securityKey, SecurityAlgorithms.RsaSha256);
_logger.LogInformation("InitializeRsaKey() successfully executed.");
}
catch (Exception ex)
{
var exception = new Exception("Identity Server RSA Key initialization failed. " + ex);
_logger.LogError(exception, "InitializeRsaKey() method failed.");
throw exception;
}
'CspKeyContainerInfo' requires Windows Cryptographic API (CAPI), which is not available on this platform. error.
Also, my project runs on a CentOS machine meanwhile I develop my project on Windows 10. So, I am aware that something existing in Windows is missing on Linux. To solve the problem any help and suggestion is appreciated.
I digged some github issues and found out that RSACryptoServiceProvider() intherits ICspAsymmetricAlgorithm and this class is supported only on Windows. For details check out here. To fix the problem I have replaced var rsaProvider = new RSACryptoServiceProvider(2048); line with var rsaProvider = RSA.Create(2048); and it works fine with .NET Core v2.2 on CentOS. Hope this helps those who have the same issue.
We are using EmbeddableDocumentStore for non-production deployments and in general it works great. I stumbled upon an issue which took me few hours to solve and it would be good to know if the behaviour I am experiencing is by design.
I init EmbeddableDocumentStore like this:
var store = new EmbeddableDocumentStore()
{
DataDirectory = dataDirectory,
DefaultDatabase = "DbName",
RunInMemory = false,
UseEmbeddedHttpServer = true,
};
store.Configuration.Port = 10001;
store.Configuration.PluginsDirectory = pluginsDirectory; // this is the important line
store.Configuration.CompiledIndexCacheDirectory = compiledIntexCacheDirectory;
store.Configuration.Storage.Voron.AllowOn32Bits = true;
store.RegisterListener(new UniqueConstraintsStoreListener());
store.Initialize();
With this setup UniqueConstraints are not working on the embedded server.
However, when I put plugins directory to it's default location (WorkingDirectory + /Plugins), it magically starts working. Is it expected behaviour?
More info:
I can reproduce it in Console app and in Web app. In web app, the default location is web root + /Plugins.
After a little bit of investigation I found out that there is a difference in how UniqueConstraints' triggers are registered in store.Configuration.Catalog.Catalogs which might have something to do with the unexpected (for me) behaviour.
With custom PluginDirectory, triggers are registered in store.Configuration.Catalog.Catalogs as BuiltinFitleringCatalog:
When bundle is in the default location, triggers are added to BundlesFilteredCatalog in store.Configuration.Catalog.Catalogs with all other default triggers:
What version of RavenDB?
In RavenDB 3.5 registering plugins on the server-side requires a magic string. Adding this to your example above will probably fix it.
store.Configuration.Settings =
{
{ "Raven/ActiveBundles", "Unique Constraints" }
};
I have a small console application doing some persistence with Raven which is working fine, but I just can't get the Raven Studio Web-App working.
I think I have read every article/blog post on the web which is around, but I haven't got it working.
The project is referencing the Raven.Client.Embedded, Raven.Client.Lightweight and Raven.Storage.Esent assemblies)
Here is the really simple code starting up my console app:
class Program
{
static void Main(string[] args)
{
EmbeddableDocumentStore store = new EmbeddableDocumentStore { DataDirectory = #"C:\temp\ravendata", UseEmbeddedHttpServer = true };
store.Initialize();
Console.WriteLine("Initialized");
while (true)
{
string line = Console.ReadLine();
if (line == "w")
{
Changeset cs = CreateChangeset();
using (var session = store.OpenSession())
{
session.Store(cs);
session.SaveChanges();
}
Console.WriteLine("Written.");
}
}
The question is: Where to put the Raven.Studio.xap in order to get it running in the browser (http://localhost:8080/Raven/studio.html)?
It's not working in the bin/debug output folder of my console app (which would be the most logical area where it should be), as well as it isn't if I put it in the root of my console application.
Sorry to ask this thing again, but it seems there is some point I am missing on this to get it up and running. ;)
Thanks for your help, R's, Rene
You are right, I've tried it using a new console application project and had the same issues, altough I copied the file Raven.Studio.xap into the \bin\debug AFTER I had seen the error message for the first time.
I found out, that the reason for this has to do with browser-caching. Even though the file would be available now, the embedded http-server returns 304 Not Modified, because it had sent the If-None-Match header into the request. Therefore, the cached "not-found" page in the browser cache will be used.
I fixed it and sent a patch to Ayende. However the solution now is:
1) make sure Raven.Studio.xap is under \bin\debug
2) clear the browsers cache