.Net Core 2 - wykorzystanie IDENTITY bez ORMa

0

Cześć, robię swój pierwszy projekt w .Net Core 2. To jest webservice.
Chciałbym osiągnąć coś takiego, żeby wykorzystać istniejący system (z Entity Framework lub bez) użytkowników (dodawanie, modyfikacja, usuwanie, autoryzacja, autentykacja, role), ale cała reszta aplikacji ma nie używać ORMa, tylko mają być normalne SQLe. Czy i jak można to osiągnąć?

Zacząłem od zaprojektowania swoich klas użytkownika (muszę mieć dodatkowe pola), UserStore itd. Ale im dalej w las, tym więcej drzew. Okazało się, że co zrobię jedną klasę, to potrzeba jeszcze kilku innych, żeby to działało. Dlatego chciałbym wykorzystać istniejący mechanizm użytkowników i nie babrać się w tym bez sensu. Natomiast w głównej części aplikacji nie chcę wykorzystywać ORMa. Jakieś wskazówki?

SZBD to MariaDb.

0

Nie jestem do końca pewien czy o to chodziło ale złączam ci tutaj plik z moim rozwiązaniem. Ogólnie ja miałem problem taki, że baza nie była moja i mogła się zmienić w każdej chwili, a łatwiej było w konfigu zmienić sql query niż przerabiać całą apkę bo entity nie radzi sobie ze zmianami w locie.

0

Nie o to mi chodziło. Takie coś mam już ogarnięte z tą różnicą, że sam pisze SQLe. Jest z tym nieco więcej roboty, ale mam dużo większą elastyczność.

Chodziło mi o to, żeby posłużyć się domyślnym mechanizmem logowania, autentykacji i autoryzacji użytkowników.
Generalnie zacząłem robić własne klasy IdentityRole, RoleStore, UserManager, UserStore itd., żeby móc uwolnić się od EntityFramework. Jednak widzę, że tych klas muszę jeszcze trochę popisać (albo robię coś nie tak), więc zastanawiam się, jak ten fragment aplikacji można by było zrobić używając domyślnych mechanizmów (nawet z EF), ale reszta aplikacji ma być już bez użycia ORMa.

0

No ja właśnie swoją apkę mam tak zrobioną. Logowanie i użytkownicy są domyślnym mechanizmem, a wymiana danych jest za pomocą metod, które ci wysłałem, z tabel, które sam stworzyłem. Napisałeś, że robisz swoje klasy, aby uwolnić się od EF, a później piszesz, że chcesz używać domyślnych mechanizmów (nawet z EF). Ja to mam zrobione w .NET Core WebPages (Razor). Logowanie mam podzielone na dwie części (tak jak ma Microsoft na swoich stronach), najpierw Email, a poźniej hasło. To jest model do podania Email. Używam UserManager i ApplicationDbContext. Baza została wygenerowana automatycznie przez Visual Studio podczas tworzenia projektu. Później tylko dodałem swoje tabelki i wyciągam z nich dane klasą jaką ci wysłałem wyżej.

public class LoginEmailModel : PageModel
    {
        private readonly string _externalCookieScheme;
        private readonly SignInManager<ApplicationUser> _signInManager;
        private readonly ILogger<LoginEmailModel> _logger;
        private readonly UserManager<ApplicationUser> _userManager;
        private readonly ApplicationDbContext _db;

        public LoginEmailModel(UserManager<ApplicationUser> userManager, SignInManager<ApplicationUser> signInManager, ILogger<LoginEmailModel> logger, ApplicationDbContext db)
        {
            _signInManager = signInManager;
            _externalCookieScheme = IdentityConstants.ApplicationScheme;
            _logger = logger;
            _userManager = userManager;
            _db = db;
        }

        [BindProperty]
        public string Email { get; set; }

        [TempData]
        public string ErrorMessage { get; set; }

        public async Task<IActionResult> OnGetAsync()
        {
            if (!string.IsNullOrEmpty(ErrorMessage))
                ModelState.AddModelError(string.Empty, ErrorMessage);

            return Page();
        }

        public async Task<IActionResult> OnPostAsync(string email)
        {
            try
            {
                var user = await _userManager.FindByEmailAsync(email);
                string redirectString = string.Empty;

                if (user == null)
                {
                    ErrorMessage = "Brak podanego u¿ytkownika w bazie danych";
                    return RedirectToPage("/Account/LoginEmail");
                }

                var bu = SQL.GetData<BazyUzytkownikow>(_db.Database.GetDbConnection().ConnectionString, $"select * from dbo.BazyUzytkownikow where UsR_UsRId like '{user.Id}'");
                var b = SQL.GetData<Baza>(_db.Database.GetDbConnection().ConnectionString, $"select * from dbo.Baza where BzD_BzDId = {bu.First().BzD_BzDId}");

                if (b.Count > 0)
                {
                    redirectString = $"/Account/LoginPassword?email={email}&firma={b.First().BzD_Nazwa}";
                }

                if (user != null)
                    return Redirect(redirectString);
            }
            catch(Exception ex) { return Redirect(Methods.ExceptionPage(ex)); }

            return Page();
        }
    }

PS.
Nie mam rejestracji, ponieważ to jest zamknięta platforma i to ja osobiście rejestruje.

0

To są PreparedStatement czy kleicie stringi (narażając się na SQL injection)?

0

Ja kleje, nie wiem co kolega robi ;)

0

Ja używam parametrów (IDbDataParameter) w zapytaniu.

Chyba już wiem, jak to mam zrobić i o co mi chodzi. Spróbuję i najwyżej później jeszcze będę pytał.

0

Tam trzeba było zaimpementować 3 interfejsy ale jakie nie pamiętam. Wpisz w nuget Identity provider for Nhibernate i zobacz jak jest zbudowany.

1 użytkowników online, w tym zalogowanych: 0, gości: 1