tugberkugurlu
commented
8 years ago @francnuec I will have a look this evening.
Closed francnuec closed 7 years ago
tugberkugurlu
commented
8 years ago @francnuec I will have a look this evening.
francnuec
commented
8 years ago Ok. Thanks. But I think the real issue is that subclasses of the MongoIdentityUser class are causing the crashes. Must it always be the direct MongoIdentityUser class used?
francnuec
commented
8 years ago From the exception, changing the private set methods of the MongoIdentityClass properties to protected might help fix this.
tugberkugurlu
commented
8 years ago changing the private set methods of the MongoIdentityClass properties to protected might help fix this
@francnuec I guess that doesn't make difference, does it? It is coming from here: https://github.com/tugberkugurlu/AspNetCore.Identity.MongoDB/blob/7406e957e328deaad62df028242dff458cfb6dae/src/AspNetCore.Identity.MongoDB/MongoIdentityUser.cs#L66 not sure why though, it could be that this mapping is not kicking in correctly: https://github.com/tugberkugurlu/AspNetCore.Identity.MongoDB/blob/master/src/AspNetCore.Identity.MongoDB/MongoConfig.cs#L38
francnuec
commented
8 years ago Well, you're right. It doesn't actually. Just tested it. But now I see the problem.
The problem is mentioned in my second comment above: subclassing the MongoIdentityClass doesn't work. This is because you registered the original Mongo Identity classes in the MongoConfig.cs class, and not their subclassed versions that a user like me could have created.
This would have been an easy fix just by enumerating all types, and then mapping them with the BsonClassMap class, but this is .NET Core, and it isn't possible to list all assembly types yet.
So the only way I see, going forward, is to delegate the BsonClassMapping to the ConfigureServices section of the Startup class such that the end user developer decides the mapping himself.
It's not ideal or user-friendly, but it would work. Else, we can never use subclasses of those identity base classes because the MongoConfig.cs class needs their custom constructors.
tugberkugurlu
commented
8 years ago subclassing the MongoIdentityClass doesn't work.
@francnuec I see, that's not good :disappointed: I think I should ditch the special mappings requirement, it will be problematic. Even with that, I am not sure if this will solve the problem. Things to do for this:
tugberkugurlu
commented
7 years ago For testing, consider https://docs.travis-ci.com/user/database-setup/
paulallington
commented
7 years ago As an interim measure, I was able to skip past this error by adding a parameterless constructor on my subclass:
public class ApplicationUser : MongoIdentityUser, IEntityWithId
{
public ApplicationUser() : base("")
{
}
...Obviously this passes a blank user, and is dangerous if used...but this seems to be a deserialisation issue and so it's setting properties correctly.
It's a temporary fix - I don't like it, but it works for now without changing any of the MongoIdentity code
tugberkugurlu
commented
7 years ago @paulallington yep, this issue ought to be solved before the stable release. It's at the top of the list https://github.com/tugberkugurlu/AspNetCore.Identity.MongoDB/projects/1.
I plan to reserve time for this project ASAP. However, feel free to PR for this if you need it urgently. If you do so, I will do my best to review, get it in and ship a new version on NuGet.
tugberkugurlu
commented
7 years ago I was able to reproduce this issue on 4734fc0.
@paulallington's workaround is OK. In addition to that, you can also work around the issue by marking your constructor with BsonConstructorAttribute:
public class MyIdentityUser : MongoIdentityUser
{
[BsonConstructor]
public MyIdentityUser(string userName) : base(userName)
{
}
public string MyCustomThing { get; set; }
}
So I tried the sample, and I kept getting this exception on Login:
Please help.