TypeSerializer SerializeToString is quote escaping strings on save to AppSettings

ServiceStack.Text
1

Hi

I think my TypeSerializer string serializer behaviour is being modified in my dotnetcore web app, but I cannot see where or how this would be happening.

I am experiencing a strange issue where (within my api app) when using the NetCoreAppSettings Get/Set functionality, a string (representing a URL, e.g “https://api.rollbar.com”) is being wrapped in extra doublequotes, so that calling:

appSettings.Set("theApiUrl", "https://api.rollbar.com");

(along the lines of https://github.com/wwwlicious/servicestack-seq-requestlogsfeature/blob/master/src/ServiceStack.Seq.RequestLogsFeature/SeqRequestLogsFeature.cs ), code here:

    /// <summary>
    /// Sets a seq server url
    /// </summary>
    public string SeqUrl
    {
        get => appSettings.GetString(ConfigKeys.SeqUrl);
        set
        {
            appSettings.Set(ConfigKeys.SeqUrl, value);
            configValidator.ValidateAndThrow(this);
        }
    }

actually saves the value setting as “'https://api.rollbar.com”"

So when I later attempt to use the HttpUtils to send a Rollbar tracing message, like so:

var rollbarLogRequest = new RollbarLogRequest();  

// Get the url to send to some the appsettings
var getApiUri = appSettings.GetString("theApiUrl");

// Next line crashes, because quote encoding of value inside the getApiUrl string breaks the parsing to new Uri() within SS HttpUtils
var responseFails = getApiUrl.PostJsonToUrlAsync(rollbarLogRequest);

// However, this works perfectly:
var responseWorks = "https://api.rollbar.com".PostJsonToUrlAsync(rollbarLogRequest);

When I attempted to verify that the appsettings setter behaviour in a separate xUnit test project, I can confirm that the strings are NOT getting quote encoded.

[Fact]
public void TestNetCoreAppSettings_ThisWorksGreat()
{
	var builder = new ConfigurationBuilder()
		.SetBasePath(Directory.GetCurrentDirectory())
		.AddJsonFile("appsettings.json", false, true)
		.AddEnvironmentVariables();

	IConfiguration config = builder.Build();
	var netCoreAppSettings = new NetCoreAppSettings(config);

	var testIndexName = "dalestest";
	var expectedValue = "daleisdoingatest";
	netCoreAppSettings.Set(testIndexName, expectedValue);
	var getItBack = netCoreAppSettings.Get<string>(testIndexName);
	var getItBack2 = netCoreAppSettings.GetString(testIndexName);

	Assert.Equal(expectedValue, getItBack);
	Assert.Equal(expectedValue, getItBack2);

	// THIS typeserializer, in a standalone test class, does NOT escape the string?
	var testingAgain = TypeSerializer.SerializeToString(expectedValue);
	Assert.Equal(expectedValue, testingAgain);
}

Could there be something funky going on when TypeSerialization is used within my appdomain, possibly due to a jsonserializer or some other setting?

(this is all driven by and based off the excellent https://github.com/wwwlicious/servicestack-seq-requestlogsfeature , which I am adapting to Rollbar, and i will release it as a nuget package once i figure this last bit out)

2

Use appSettings.Get<string>() to fetch values created by appSettings.Set<string>().

3

No improvement I am afraid. I can manually correct this doing the commented out string.replace operations, but it seems hacky and leaves me wondering what is modifying the behaviour.

public string RollbarUrl
{
	get => _appSettings.Get<string>(RollbarConfigKeys.RollbarUrl); //.Replace(@"\", "").Replace("\"", "");
	set
	{
		_appSettings.Set<string>(RollbarConfigKeys.RollbarUrl, value);
		_rollbarConfigValidator.ValidateAndThrow(this);
	}
}

When the validator runs, it’s the same issue - the value that the property getter returns is still modified, and the validator uri check fails in the same way as the HttpUtils ToPostUrl stuff in my initial post.

internal class RollbarConfigValidator : AbstractValidator<RollbarLogsFeature>
{
	public RollbarConfigValidator()
	{
		RuleFor(cs => cs.RollbarUrl)
			.NotEmpty()
			.Must(x => Uri.IsWellFormedUriString(x, UriKind.Absolute))
			.WithMessage("Rollbar Api Url is not a valid url");
	}
}
4

Ok looks like an issue with interoperating with the back-end IConfiguration store. I’ve removed serialization of string values in this commit which should now be working as expected. This change is available from the latest v5.0.3 that’s now on MyGet.

1 Like