XNADash ported to .NET8/Monogame

Years ago, in 2011, I've blogged about an old DOS game I've ported to XNA. This weekend I've found the code and spent a while to make sure it works.

The new version targets .NET8/Monogame and is available on my Github.

OldMusicBox.ePUAP.Client 1.25.3

Bumped the OldMusicBox.ePUAP.Client to 1.25.3.

For some unknown reason that doesn't seem to be announced, the TpSiging5::GetSignedDocument changed the format of natural person's data (givenname, surname, personal identification number).

From the very beginning of the old TpSigning service, the document contained user signatures in the PodpisZP node. Later on, when TpSigning5 was introduced, they changed the signature to EPSignature node (different node with different model).

And guess what, starting from somewhere between 07-03-2025 and 10-03-2025, the new service (TpSigning5) returns the natural person's data in the old format (back to PodpisZP). Be aware of this and update your code accordingly.

Yet another ASP.NET Core JWT tutorial?

Why would you need yet another ASP.NET Core JWT tutorial?

Well, becuse most of them are unnecessarily complicated. Some involve unnecessary APIs like the Identity API. Some try to introduce an OAuth2/OpenID Connect stack. There are ocassional cases where false assumptions are used to justify the need of JWT tokens.

An example of the latter is an argument that "cookies are bad since they require data stored in server's session container", given here. Of course, cookies do not require that anything is stored in the container session, a cookie can just contain a username and this is how authentication cookies are often used. Anyone using .NET cookie authentication for years would be surprised to hear that instead of just a username, an ASP.NET authentication cookie would contain a session ID and the server would only lookup user data at the server's session container.

It's not that unnecessarily elaborated demo or a demo that fails at some subtle reasons is bad. It's just harder to follow.

Why would you prefer JWT from cookies then?

There's only one valid argument: JWT tokens work crossdomain, cookies don't. In a setup where an authentication token is issued at domain A and is required at domain B, cookies don't work. JWT tokens on the other hand, are usually put in custom headers in web browser calls and thus can be easily sent anywhere.

What would I personally expect from a JWT tutorial?

Well, I'd expect following:

• a web app that authenticates users somehow, could even be an endpoint that accepts a username/password pair but an easy approach would be a cookie-based authentication with a usual login page. An advantage of the latter is that I expect a good demo to show how to have both in a single app: a cookie-based authentication on some endpoints and JWT based authentication on other endpoints
• I want to see an endpoint that is set up to issue JWT tokens then. The endpoint could assume the user is authenticated (e.g. with an already issued cookie) and would just create JWT containing the username
• I want to see a data endpoint that is authenticated only with a JWT token, a cookie should not be accepted. The endpoint could be exposed on the very same app but I'd easily think of any other app (a different domain) exposing it
• I don't want any extra frameworks, APIs, anything, just bare minimum

And what? And there it is, https://github.com/wzychla/AspJwtBearerDemo. A complete demo. Here's an overview:

• the demo contains both MVC and WebAPI controllers
• there are two MVC controllers, the Home controller is only accessible by users authenticated with a cookie, the Account controller is used as a default redirect for unauthenticated calls and uses SignInAsync to issue the cookie
• as long as the cookie is issued, the Home::Index view is rendered
• there are two active endpoints
• first, the Token::Acquire is used to get the JWT token. Note how easy it is: the used should be authenticated somehow (= cookie in my demo) and the code just creates a plain JWT with just the username
• then, the Data::Get WebAPI endpoint is secured with the JWT token. Note that by configuring the JWT stack to recognize the JWT name claim as username I can access this.User.Identity.Name in a WebAPI code and still have the username. The this.User.Identity.Name is then used in the very same way in both MVC cookie secured controllers and WebAPI JWT secured controllers. The key point of this JWT config is

  cfg.TokenValidationParameters = new TokenValidationParameters()
  {
     ValidateAudience = false,
     ValidateIssuer   = false,
     IssuerSigningKey = signingKey,
     NameClaimType    = "name"     // map JWT's name claim to NET's IPrincipal::IIdentity::Name
  }; 
  

What is actually really nice in ASP.NET Core is the idea of authentication scheme - we define multiple authentication schemes (in this demo, there are two: cookie based and JWT based) and then each time Authorize is used on an action (both MVC and WebAPI) we specify which authentication scheme should is accepted. Thus, having some endpoints secured with a cookie and other secured with JWT tokens is easy and clean.

That's it. Clone the Github demo, follow the flow, take a look how both schemes are configured in AddCookies and AddJwtBearer. Enjoy.

Using Task.WhenAny to time bound a task

Just for a future reference - suppose a task should not take longer than ... but there's still a need to finish it. It's just the caller that cannot wait longer

One of use cases involves a REST service where you provide the server part. There's a client that should get an answer in max X seconds, regardless of whether the actual task finishes or not. You want a timer that runs together with the task and in case any of the two finishes first, you want to know which one was it.

Let's stage actors first:

public class TaskExperiments
{
	public async Task<string> DelayWithEcho( int ms, string echo, string id )
	{
		await Task.Delay( ms );
		Console.WriteLine( echo );

		return id;
	}
}

This one above is supposed to be a factory of tasks. A task is given a time and an id so that when it finishes, I know the id.

Now, the runner:

var e = new TaskExperiments();

var t1 = e.DelayWithEcho( 5000, "Task1 after 5000ms - time constraint", "i1" );
var t2 = e.DelayWithEcho( 3000, "Task2 after 3000ms - actual task",     "i2" ); 

var t  = await Task.WhenAny( t1, t2 );
var id = await t;

Console.WriteLine( $"Finished one of the two : {id}" );

As you can see, Task.WhenAny is used and then the result task is awaited once again to get the id.

Running this gives:

Task2 after 3000ms - actual task
Finished one of the two : i2
Task1 after 5000ms - time constraint

Now change the second to last longer:

...
var t2 = e.DelayWithEcho( 7000, "Task2 po 7000ms - actual task",     "i2" ); 
...

and the result is

Task1 after 5000ms - time constraint
Finished one of the two : i1
Task2 after 7000ms - actual task

Hobby, reloaded

Rust/WebAssembly vs Javascript performance ... reloaded

Last year I've blogged about a tiny contest where Rust/WASM and Javascript were used to implement a simple Mandelbrot animation. I've polished the code, put it in a github repo, the rust-vs-js. I've also added a third contestant, the gpu.js accelerated version, which of course beats the heck out of the two (Javascript and Rust) since it's heavily parallelized.

Anyway, jump to the repository and enjoy the code.

Take just a single visible character?

Fairly simple requirement - get a first letter of profile description and present it together with a link. You get the idea, if I have two profiles, Foo and Bar, I want two links with F and B respectively.

The first version of the code (not even mentioned here) was just something like: if string has at least one character, take uppercase of the first character.

This seemingly simple approach completely ignores Emojis which are handled in C# strings as two consecutive chars. The second version of the code was then:

public static string ToShortDescription( this string source )
{
	var description = source?.Trim();

	if ( !string.IsNullOrWhiteSpace( description ) && description.Length >= 1 )
	{
		if ( char.IsSurrogatePair( description, 0 ) )
		{
			return description.Substring( 0, 2 ).ToUpper();
		}
		else
		{
			return description.Substring( 0, 1 ).ToUpper();
		}
	}

	return "?";
}

This is better, much better. It's not just the first character of the string, it's the substring that has the length of 2. This simple approach correctly handles many two-char Emojis, like the male mage Emoji, 🧙, encoded as 🧙.

Unfortunately, it's just the beginning of the story. It turns out some Emojis are combined from other Emojis. Let's take the mage emoji. Its female version, 🧙‍♀️, is encoded as male mage Emoji followed by additional characters to indicate female version (🧙‍♀️). The special character used to glue together emojis is the Zero-Width-Joiner (ZWJ).

Take a C# string that starts with the female mage emoji. This time it's not the 2 characters that should be taken from it, now it's 5! The two-char Emoji, the ZWJ, and another two-char Emoji!

Let this sink in - in order to have a single visible character on the screen, we need to take 5 first characters of the C# string!

And as you can expect, the above version of code correctly discovers the first surrogate but fails to discover the ZWJ.

There's even a discussion on SO on how to detect this.

My current approach is

public static string ToShortDescription( this string source, bool autoUpper = true )
{
	var description = source?.Trim();

	if ( !string.IsNullOrWhiteSpace( description ) && description.Length >= 1 )
	{
		// należy brać kolejne znaki na następujących zasadach
		// * jeśli zwykły znak - bierze się i koniec
		// * jeśli zjw - bierze się i nie koniec
		// * jeśli surrogatepair bierze się dwa i nie koniec
		char[] sourceChars = source.ToCharArray();
		List<char> destChars = new List<char>();

		var index = 0;
		bool takeAgain;
		bool zjw;

		do
		{
			takeAgain = false;

			// czy jest jeden i jeszcze jeden za nim (dwuznaki)
			if ( index < sourceChars.Length - 1 )
			{
				// surogat
				if ( char.IsSurrogatePair( sourceChars[index], sourceChars[index + 1] ) )
				{
					destChars.AddRange( new[] { sourceChars[index], sourceChars[index + 1] } );

					index    += 2;
					takeAgain = true;
				}
			}

			if ( index < sourceChars.Length - 2 )
			{
				// zjw - skleja dwa emoji
				if ( sourceChars[index] == (char)8205 )
				{
					destChars.AddRange( new[] { sourceChars[index], sourceChars[index + 1], sourceChars[index + 2] } );

					index    += 3;
					takeAgain = true;
				}

			}


		} while ( takeAgain && index < sourceChars.Length );

		// weź jeszcze jeden jeśli jeszcze nie ma nic lub zjw
		if ( !takeAgain && 
			 index <= sourceChars.Length-1 &&
			 destChars.Count == 0 
			)
		{
			destChars.Add( sourceChars[index] );
		}

		string _result = new string( destChars.ToArray() );

		return autoUpper ? _result.ToUpper() : _result;

		/*
		if ( char.IsSurrogatePair( description, 0 ) )
		{
			return description.Substring( 0, 2 ).ToUpper();
		}
		else
		{
			return description.Substring( 0, 1 ).ToUpper();
		}
		*/
	}

	return "?";
}

This passes some important unit tests. Namely, it correctly handles the England Emoji flag emoji, the 🏴󠁧󠁢󠁥󠁮󠁧󠁿 (🏴󠁧󠁢󠁥󠁮󠁧󠁿), which still is a single visible sign but in this extreme case it's the first 14 characters of the C# string! I believe there's still a room for improvement (and possibly other strange cases that I still miss).