One of the most important aspects of this project was to leverage the user logins that the club members already use to access the club forum. I had already done some proof of concept work around this. The forum doesn't have an API, but I could make requests to the login and profile pages to verify a user and get their privileges.
I decided in the end to perform a user synchonisation when the user logs in. This ensures that the app has access to the user's non sensitive details. The user can see this information on their profile page.
This is the same information that is accessible on the forum system by all users. Having this information at hand in the app puts the development on a good footing going forward.
The benefits of this approach:
- Less duplicated user data (than storing against each trip sign up)
- Know who has logged in, for support issues
- Closer alignment to the standard identity model
- Cleaner separation of claims to roles.
Joining a Trip
Two additional user stories were completed this sprint:
- List all open trips
- Join a trip
'List all open trips' is a view that is shown straight after logging in and all users can see it. If you are a paid up member, you will be able to join the trips. Once joined a trip, this view will allow the member to proceed directly to the planning view.
If you are only a registered user, you will be able to look at the trips but not join
Authorisation
Three features of the Angular - ASP.NET Core API stack were used to secure the Join a trip feature, which is a member's only feature
- On the API endpoint an [Authorize] attribute was added to adhere to an authorisation policy that had been set up to check the member's claims.
- On the Angular trip planning page an authorisation guard was added.
- On the Join button a has-role directive was added to hide the button for users that were not members.
Testing
On the Angular side, I've been getting some good coverage using the HttpTestingController to mock the http calls. This has meant that I can test the components and some of the services as a single system-under-test (SUT).
Mocking out Activated route took a while to work out, but solution found here.
Another tricky mocking was the RouterOutlet. This required adding CUSTOM_ELEMENTS_SCHEMA to the schemas section in the test bed. A couple of Stack Overflow's router-outlet and another.
Found an article for a deeper dive into testing around routed components.
No comments:
Post a Comment