We Keep Coding

What is the difference between graphql-dotnet/graphql-dotnet/ and graphql-dotnet/server/

Good morning.
I am a bit confused about these two repositories(graphql-dotnet/graphql-dotnet/ and graphql-dotnet/server/).
https://github.com/graphql-dotnet/graphql-dotnet/ and
https://github.com/graphql-dotnet/server
They are both under the same organization and there is some overlap of contributors, but I'm a bit lost about deciding which one to use.
I would like to build a dotnet 5 application that hosts a graphql endpoint. In a nutshell that is my goal.
I noticed that the graphql-dotnet/server/repository has inbuilt some helpers such as.
serviceCollection
.AddGraphQL((options, provider) =>
{
options.EnableMetrics = HostEnvironment.IsDevelopment();
var logger = provider.GetRequiredService<ILogger<Startup>>();
options.UnhandledExceptionDelegate = ctx => logger.LogError("{Error} occurred", ctx.OriginalException.Message);
})
.AddSystemTextJson()
.AddErrorInfoProvider(opt => opt.ExposeExceptionStackTrace = HostEnvironment.IsDevelopment())
.AddWebSockets()
.AddDataLoader()
.AddGraphTypes(typeof(ApplicationSchema))
Which allows my DI to be setup nice and easy. Its counterpart, the graphql-dotnet/graphql-dotnet/ does not.
So my question is "which one should I use exclusivly? Which one is recomended, by secondary goals are to add jwt authentication and finally federation support. But those two are far down the line.
One of my coworkers went ahead and used graphql-dotnet/graphql-dotnet/ and his server application has a lot more configuration than the documentation of graphql-dotnet/server/ so how do I know which one do I use?
Can any one recommend any documentation that highlights the difference between the two of them?

The main graphql-dotnet repo is the "core" library of GraphQL components. The server repo contains ASP.NET specific extensions. It uses the core library. If you use the server project, you are also using the core library.
GraphQL itself can be used with any protocol, it is not required to be used with HTTP or JSON. So the core library does not have any HTTP or ASP.NET dependencies.
If you are using ASP.NET, then the server project is the quickest way to get started. If you want to use Subscriptions, then the server project provides that functionality.
If you don't need subscriptions and if you want a bit more control over how the framework handles the HTTP request, then it would be easier to write your own controller or middleware.
Using JWT authentication is handled by ASP.NET and can be used in either scenario. Federation can also be used in either scenario.

How to specify the API version?

According to the Azure DevOps Services REST API Reference, the request URI has the following format:
https://{instance}[/{team-project}]/_apis[/{area}]/{resource}?api-version={version}
Regarding the api-version:
Every API request should include an api-version to avoid having your app or service break as APIs evolve.
I started using the .NET client libraries for Azure DevOps Services (and TFS) to manage dashboards programmatically.
I am able to connect to Azure DevOps using a Personal Access Token:
var credential = new VssBasicCredential(string.Empty, "PersonalAccessToken");
using (VssConnection connection = new VssConnection(new Uri("...."), credential))
using (var client = connection.GetClient<DashboardHttpClient>())
{
// ...
}
How can I specify the API version? Does it still make sense to do it, when using the .NET client libraries?

The API version is decided by the client libraries. You can confirm this by disassembling them (e.g. using ILSpy).
For example, in the current stable release of Microsoft.TeamFoundationServer.Client, DashboardHttpClientBase has a CreateDashboardAsnc method that makes the following call:
this.SendAsync<Dashboard>(..., new ApiResourceVersion("4.1-preview.2"), ...);

ServiceStack: how to use distributed RedisEvents?

There is very little documentation (that I found) on how the distributed RedisEvents work in ServiceStack.
The documentation says:
One limitation the default MemoryServerEvents implementation has is being limited for use within a single App Server where all client connections are maintained. This is no longer a limitation with the new Redis ServerEvents back-end which utilizes a distributed redis-server back-end to provide a scale-out option capable of serving fan-out/load-balanced App Servers. If you’re familiar with SignalR, this is akin to SignalR’s scaleout with Redis back-end.
It also says how to add the plug-in, but then there is nothing else on how events are distributed, how you post a distributed event and how you handle what node to react to it and post to channel that will reach the correct end-client.
Am I missing something or is there almost no documentation on this?

The documentation for RedisServerEvents is at: http://docs.servicestack.net/redis-server-events
There is no difference in API between using an In Memory or Redis Server Events backend which works transparently behind the IServerEvents API. The only difference is in registration where you need to register RedisServerEvents with your configured IRedisClientsManager:
var redisHost = AppSettings.GetString("RedisHost");
if (redisHost != null)
{
container.Register<IRedisClientsManager>(
new RedisManagerPool(redisHost));
container.Register<IServerEvents>(c =>
new RedisServerEvents(c.Resolve<IRedisClientsManager>()));
container.Resolve<IServerEvents>().Start();
}
This replaces the default Memory IServerEvents with the RedisServerEvents implementation which sends API calls over Redis Pub/Sub to notify all App Servers configured with the same RedisServerEvents configuration who will send the Server Event to the connected clients on their local /event-stream.

Which versions of SSL/TLS does System.Net.WebRequest support?

Now that SSL 3 has been found to be vulnerable to the POODLE attack:
Which versions of SSL/TLS does System.Net.WebRequest use when connecting to any https Uri?
I use WebRequest to connect to several 3rd party API's. One of these has now said they will block any request that uses SSL 3. But WebRequest is part of the .Net core framework (using 4.5) so it is not obvious what version it uses.

This is an important question. The SSL 3 protocol (1996) is irreparably broken by the Poodle attack published 2014. The IETF have published "SSLv3 MUST NOT be used". Web browsers are ditching it. Mozilla Firefox and Google Chrome have already done so.
Two excellent tools for checking protocol support in browsers are SSL Lab's client test and https://www.howsmyssl.com/ . The latter does not require Javascript, so you can try it from .NET's HttpClient:
// set proxy if you need to
// WebRequest.DefaultWebProxy = new WebProxy("http://localhost:3128");
File.WriteAllText("howsmyssl-httpclient.html", new HttpClient().GetStringAsync("https://www.howsmyssl.com").Result);
// alternative using WebClient for older framework versions
// new WebClient().DownloadFile("https://www.howsmyssl.com/", "howsmyssl-webclient.html");
The result is damning:
Your client is using TLS 1.0, which is very old, possibly susceptible to the BEAST attack, and doesn't have the best cipher suites available on it. Additions like AES-GCM, and SHA256 to replace MD5-SHA-1 are unavailable to a TLS 1.0 client as well as many more modern cipher suites.
That's concerning. It's comparable to 2006's Internet Explorer 7.
To list exactly which protocols a HTTP client supports, you can try the version-specific test servers below:
var test_servers = new Dictionary<string, string>();
test_servers["SSL 2"] = "https://www.ssllabs.com:10200";
test_servers["SSL 3"] = "https://www.ssllabs.com:10300";
test_servers["TLS 1.0"] = "https://www.ssllabs.com:10301";
test_servers["TLS 1.1"] = "https://www.ssllabs.com:10302";
test_servers["TLS 1.2"] = "https://www.ssllabs.com:10303";
var supported = new Func<string, bool>(url =>
{
try { return new HttpClient().GetAsync(url).Result.IsSuccessStatusCode; }
catch { return false; }
});
var supported_protocols = test_servers.Where(server => supported(server.Value));
Console.WriteLine(string.Join(", ", supported_protocols.Select(x => x.Key)));
I'm using .NET Framework 4.6.2. I found HttpClient supports only SSL 3 and TLS 1.0. That's concerning. This is comparable to 2006's Internet Explorer 7.
Update: It turns HttpClient does support TLS 1.1 and 1.2, but you have to turn them on manually at System.Net.ServicePointManager.SecurityProtocol. See https://stackoverflow.com/a/26392698/284795
I don't know why it uses bad protocols out-the-box. That seems a poor setup choice, tantamount to a major security bug (I bet plenty of applications don't change the default). How can we report it?

When using System.Net.WebRequest your application will negotiate with the server to determine the highest TLS version that both your application and the server support, and use this. You can see more details on how this works here:
http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake
If the server doesn't support TLS it will fallback to SSL, therefore it could potentially fallback to SSL3. You can see all of the versions that .NET 4.5 supports here:
http://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.110).aspx
In order to prevent your application being vulnerable to POODLE, you can disable SSL3 on the machine that your application is running on by following this explanation:
https://serverfault.com/questions/637207/on-iis-how-do-i-patch-the-ssl-3-0-poodle-vulnerability-cve-2014-3566

I also put an answer there, but the article #Colonel Panic's update refers to suggests forcing TLS 1.2. In the future, when TLS 1.2 is compromised or just superceded, having your code stuck to TLS 1.2 will be considered a deficiency. Negotiation to TLS1.2 is enabled in .Net 4.6 by default. If you have the option to upgrade your source to .Net 4.6, I would highly recommend that change over forcing TLS 1.2.
If you do force TLS 1.2, strongly consider leaving some type of breadcrumb that will remove that force if you do upgrade to the 4.6 or higher framework.

Why did adding a line of code to expire the header on a page break IIS? [duplicate]

I am using IIS6, I've written an HttpModule, and I get this error? After googling the web I find that this problem is caused by the .NET framework 3.5, so I put this on a machine where I didn't install .NET 3.5, but the problem is still there!

My attempt at psychic debugging: you're using a statement like:
Response.Headers("X-Foo") = "bar"
If this is indeed the case, changing this as shown below will work around the problem:
Response.AddHeader("X-Foo", "bar")

Only IIS7 supports the integrated pipeline. On IIS7 a HttpModule can participate in all requests coming to the web server not just those targeting specific file extensions.
II6 uses what IIS7 calls the classic pipeline where a HttpModules can only get involved once the earlier ISAPI based pipeline determines that the script mapping requires the request to handed over to ASP.NET.

Just came across this problem. Using IIS6 and .NET 3.5. Fix for me was to use Response.AddHeader instead of Response.Headers.Add. HTH.

Inspired by other answers, I've found that it's accessing the Response.Headers object that causes the "operation requires IIS integrated pipeline mode" exception.
Avoid .Headers and call other (older?) helper functions like:
Response.AddHeader() and
Response.ClearHeaders() (in my case!)