I am just looking into .Net Core's Identity system for authentication I have a home screen (a razor page with #page "/") that has a login form. I would like to use this login form to authenticate the user.
Every example I've seen seems to use Areas/Identity/Pages/Account/Login.cshtml generated from the Identity.UI package, I would like to avoid this and ideally I would like to be able to authenticate a user from a Razor component thus allowing me to authenticate from any page.
However, from what I've read for reasons I don't yet understand fully that's not possible. I'm not sure if this information is out of date.
So, is it possible to authenticate a user using _signInManager.PasswordSignInAsync from a razor page or component in .NET 5?
Related
I've been searching around and couldn't find a good solution to this.
I'm working on a school project that built upon HTML (Making a bunch of pages) -> CSS (Styling the pages) -> JS (Adding some functionality) and finally backend using whatever we want.
I've used mongodb and node/express to have a functional sign up and login and it works via POSTMAN, but I'm not sure how to connect that to my existing html file that was made for a prototype sign up/login.
Any advice?
There's several things you need to consider.
If the goal is to authenticate users through your backend you need a way for your front end to communicate to the backend and check whether or not the user is logged in. To do this you'll need the express server to validate the user's login information and send a token back to the user. The user can then use this token to access protected routes on the server.
You can send a POST request to your server containing the login information with the axios library, and have the server redirect the user to a protected url upon a successful request.
I couldn't explain how to do this in this post alone, but here's an excellent tutorial on how to get started.
authentication tutorial
It sounds like you already know what to use for backend, but not frontend.
You need to choose frontend such as React, Angular or Vue.js etc.
and connect your backend to the Server if it makes sense to you.
I recommend to look up React tutorial ( Or any other Frontend ) and move your HTML, CSS and JS to the project first.
Good day everyone. I am stumped at the moment and would appreciate some guidance. I feel like I am a great googler to usually find my answers or resources but for the life of me I can't seem to find any good learning material on JSON requests and responses.
So I took a course that builds a 3 part app. Web app with Django, and 2 mobile apps that make API calls to it. The instructor uses Facebook authentication from the mobile apps and I am trying to set up the apps for username and login and a registration page as well.
I have django models setup and and can make users from the web app but I can't seem to wrap my head around how to make JSON calls from app to Django. When I search for possible terms like authenticate django I get results that talk about only django usage.
Does anyone have some tips or links to resources that would help me understand the login process better. I realize that almost every app has a login which is why I'm surprised that I can't find any good learning material on how its done. Or I'm just searching for wrong keywords.
Any help would be great thanks.
It's really a general question, But i give you a brief on how mobile and django server should interact with each other:
First of all, in your situation I really suggest to use django rest framework, Because of it's rich modules and functionallity like serializers, routers and ...
read more about it from origin documentation here.
For authentication system, You should use a token based system (or session). I suggest use one of django suggested token based solutions for that. In my case i really suggest to use django-restframework-jwt library
(JSON Web Token Authentication support for Django REST Framework).
so whenever you want to send a request to mobile you should provide that token (based on token authentication backend you choose) in your headers of request.
And for login and register you should create APIViews that takes user input, then register or authenticated it with backend and then gives user the generated token for future requests.
And for social auth system like facebook, the main concept is to redirect user from app to facebook oauth links, which if the user authenticate in his facebook will redirect you redirect url of your backend server, then you should capture that request in callback, fetch data and create or get the user and generate the token for that user and return it. so that for furture requests, by sending token to server, server will know that which user is sending this request and handle response properly for that.
And if you want to create a login with mobile, then you need to setup APIs for login, register with django rest which is really easy and you can learn from it here.
This question comes from the following post:
OWIN cookie authentication get roles on client side
I've created a separate thread for the question since it is more general than one in the post above.
In short:
Let's say we have a web application with javascript as client side + ASP.NET web api as server side and also an identity server. Only authenticated users can access web api endpoints, some of them accessible only for specific roles of user.
Now the client side of application should show specific items based on what role user is in. For example: user in administrator role can see an extra tab: manage items. There are two approaches to achieve this:
When rendering client side application, one could call an endpoind in web api which would return what roles user have. Based on that result, show/hide items in html.
When application loads, an endpoint, which returns how the structure should look like (for example: json string) would be returned, and based on that structure client application would be rendered. No show/hide html on client side based on roles in such case.
Now regarding 1st point: some could argue that there is a security leak, since malicious user can modify html to see elements that he is not supposed to see. But in this case he will not see any content from database and will not be able to load/update it since he will not be authorized to do that based on his role which is checked in server side.
2nd point seems more valid since we keep all identity related information logic on server side. And also all unnecessary content is not in html (while in 1st point it's hidden) - so that leads to better performance? In this case though if for example developing angular application, the json structure of application should include such information as name of angular controller and route for example. Would that not add complexity to developing application?
Assume that the application itself have a lot of roles and a lot of items should be visible/not visible based on these roles.
Pros/cons between 1st and 2nd? Thanks!
I stick always with the first suggested point.
As you mentioned the second choice will add more complexity for developing. For the 1st there is no security leak. If you don't want your users to modify the html and to access forbidden areas in your application simply use ng-if instead of ng-show. If you are not familiar - ng-if will not just hide the content with display: none;. It will completely remove it from the DOM and this leading the user unable to show that content as it is not in the DOM.
Read this for more detailed explanation for ng-if and ng-show: what is the difference between ng-if and ng-show/ng-hide
I usually have an endpoint getting information about the user - including it's role and save that user into a service (factory). This gives me the flexibility to use it everywhere in the application and check if the user has access or not to certain parts of it.
I am trying to implement a small application using Swing and MVC Design Pattern with MS SQL Server as the backend.
The application starts with a simple login form. Also there are two kinds of roles for the users of the application.
Administrator: Can create, delete, modify, view all users plus all the functionality the application provides.
Application Users: Can only use the functionality the application provides.
I'm thinking to have two separate Frames i.e. UI for each role.
The main login form/GUI acts as a view, with a Login controller class which registers the view using Observer pattern. The button registers the event, which the controller listens, calls the appropriate DAO to connect to database and verify if the user can log on to the application.
The stored procedure for login returns access_role i.e. either administrator, application user, unknown user or non-authenticated user which is returned through DAO back to Login Controller.
I want to keep the coupling as low as possible, hence the separation of concerns and MVC design with Observer Pattern.
Now my questions are,
Should the Login controller decide based on the access_role returned to show either the application user UI or the Administrator UI or should it pass that information back to the Login UI which should initialize the respective GUI ?
If the Login Controller should decide which UI to initiate, then it would need to set all listeners as well for the respective GUI? Is that a good design decision or is there a better way of doing this?
If the Login Controller passes the access_control back to the Login Form, then that Login Form would have to initialize all the Listeners for the new GUI and instantiate the new GUI as well? Is this better than the controller doing the stuff?
Should the UI for Administrator and Application User be JFrame or Dialogs ?
Hoping to hear your views about it.
Best regards,
Kashif Khan
I'm not sure if I would want the Login Controller or the Login UI initialize a different part of my application. In the interest of keeping things decoupled I would want the Login stuff to handle no other function but logging in a user. It might be a good idea to have like a Application Controller that initializes the Login part of your application and when it authenticates a user pass that message back to it which will decide which GUI needs to be initialized next.
As stated in part 1, the the Login Controller should just pass a message back to the Overall Application Controller which will make a decision on which part of the Application needs to be initialized next.
It would seem out of scope of the Login Form to handle all of these actions. The Login form should merely just communicate to the Application controller whether login was successful or not and some basic information about the user so additional information can be gathered as needed from the database on during the next part of initialization.
From the JDialog Oracle Documentation "A Dialog window is an independent subwindow meant to carry temporary notice apart from the main Swing Application Window" This being said you wouldnt want to use Dialogs for your main application. You could however use a Dialog for the Login form if you chose to and that would be acceptable.
I hope this helps.
I'm playing with the idea of having a completely decoupled HTML5 frontend, but still user authentication for a web app. Is this possible or will I run into some heavy browser security issues?
The idea is to have all static content delivered through a CDN on like example.com, and having it fetch dynamic data (and user authentication) through a separate subdomain, like api.example.com.
This would speed up the loading time of the site, and I could keep the frontend stuff in a completely separate repo so that the developers don't have to worry about setting up the backend to develop and test new features.
Is this already possible in some JS framework perhaps, backbone.js, angular.js, ember.js, knockout.js ?
It definitely is, but I think it is more about approach rather than technology. I have implemented what you describe for a project (it's online but don't want to do a shameless plug here, if interested to check it out I can post the link). My stack is java in the backend exposing a REST api for both autentication and business logic. The client is a backbone.js application. I explicitely decided NOT to use sessions at all. It is completely stateless. This of course means that the user must be re-authenticated at every request.
When the user logs in through a slightly modified OAuth endpoint, it gets a token that must be passed at every request. Cookie works in this case as they are handled automatically by the browser. If not passed as cookie, the backend expect it as a parameter. The frontend communicates using the REST endpoints. It's a single-page application, full client side, this means that the backend serves a page that is basically empty, that include few JS files that are the application itself. No other pageload occurs. Logout is done by simply deleting the cookie or not sending the authToken, the server cannot and doesn't have to "forget" about the user. Token are nice as they can be invalidated, both expilcitely or by changing the password. I've chosen this approach as it made it easy to develop desktop app and browser plugin for my webapp without touching a single line of backend code.