Hi,
I need some advice to build an angular front end. Basically, the goal is to have a ticket system management.
Then I need to have a way for an anonymous user to submit a ticket. This ticket will be stored in database and accessible to back end users.
I would like a very simple way to submit a ticket. Just a form with a Captcha. Anonymous user has to provide its email and a request message. A submit button to send the form. if email provided is recognized by backend, then a ticket is created and stored in database. If not, a popup is shown to anonymous user displaying a message that he has not been recognized.
As a second step, this anonymous user should be able to see a list of previous requests submitted to check there status (open, close). A simple login form with an email and password is needed to have access to this list.
I can see two solutions : 1- Create an additional angular page directly to the account module (which doesn't require auth) 2- Create a specific module based on account module (but need more time to do and may be some adaptations of angular routes)
What solution would you choose in this case ?
How would you manage this new simple authentication system (email + password) ? Should I use your existing ABP user mechanism with a static role that will limit anonymous user to a specific Angular Module OR should I do it on my own with very limited features (login, logout, forgot password, create new ticket, ticket list)
Suggestions and advices would be much appreciated ;)
2 Answer(s)
-
0
if email provided is recognized by backend, then a ticket is created and stored in database. If not, a popup is shown to anonymous user displaying a message that he has not been recognized.
As a second step, this anonymous user should be able to see a list of previous requests submitted to check there status (open, close). A simple login form with an email and password is needed to have access to this list.
The first step is an unauthenticated user accessing an [AbpAllowAnonymous] endpoint. The second step is just regular authentication.
I can see two solutions : 1- Create an additional angular page directly to the account module (which doesn't require auth) 2- Create a specific module based on account module (but need more time to do and may be some adaptations of angular routes)
What solution would you choose in this case ?
Go with 2, since they really are different modules — and should have different routes.
How would you manage this new simple authentication system (email + password) ? Should I use your existing ABP user mechanism with a static role that will limit anonymous user to a specific Angular Module OR should I do it on my own with very limited features (login, logout, forgot password, create new ticket, ticket list)
Well, "email + password" is just regular authentication. Use the existing ABP user mechanism with a role. That's what roles are for.
-
0
@aaron : thank you for your help.
I decided to create two additional pages on account module : this allows anonymous user to submit a ticket with its email address :
- If emailaddress is recognized, then a ticket is created and an email is sent to him with a link and a password to connect to backend.
- If emailaddress is not recognized, then a user is created automatically before ticket creation. Like above, an email with its credentials is sent.
I'm using classic auth has you suggested
Being in same angular account module was easier and allows to open login page, forgot password... and all other pages in this module.
I'm not going to use a specific role for this kind of user... in fact, this users are considered as "externals" and should NEVER have access to the entire backend application and functionnalities (like chat feature).
To do this, I'm planning to extend user entity with a boolean property "IsExternal". But I'm facing some chalenges with this design like :
- separating permissions for classic users and for external users
- if possible, be able to dedicate roles for classic users and roles for external users
- adapting user repository to display classic users OR external users (but never displaying both)
- avoiding to add a role or a OU to an external user
