The JWT should match "accounts.google.com" or "https://accounts.google.com". If
it doesn't, we produce a validation error.
TL;DR:
- Group all failed stringOrURI function calls as StringOrURIParseFailure errors
I'm attempting to be an obedient boy and implement this and future features
using TDD.
TL;DR:
- Defined a few tests
- Defined an empty GoogleSignIn module
- Defined a Fixtures module to quickly create JWTs to test
TL;DR:
- Add common dependencies like Servant, Aeson, Warp, Cors
- Define a POST /verify endpoint for our client to hit
- POST to /verify client-side onSignIn
Using Haskell's Text.ParserCombinators.ReadP library for the first time, and I
enjoyed it thoroughly! It's nice avoiding a third-party library like MegaParsec.
Before starting my take-home assignment, the instructions advised me to create a
"Hello, world" program in the language of my choice. Since I'm choosing Haskell,
I created this example as my starter boilerplate.
I think setting -Wall is a sensible default and @dmjio confirmed this. After
putting this in my project's .ghci file, a few dozen warnings emerged. This
commit changes the code that causes the warnings.
Create a project-local .ghci file to define sensible
defaults (e.g. -Wincomplete-patterns).
TODO: Discover more GHC options to put in this file.
I would prefer to keep this at the project root, but because I'm running the
project from the src directory, I need to keep .ghci there.
Two things:
1. I've never attempted to support this before.
2. It seems surprisingly and perhaps deceptively simpler than what I
expected. I'm unsure what to do once Google's API authenticates the user. I
currently look-up the user's role, trips, etc. using their email address. The
role is stored in the Accounts table alongside username, email, password. I
will speak with the interviewer tomorrow about this.
TL;DR: My trips.csv had invalid dates for the endDate column. "2020-15-30" is an
"invalid date" (according to FromField instance for Calendar.Day) bc 15 is not a
valid month (i.e. [1,12]).
@dmjio helped me take a look. When we poked around the SQL, we discovered:
```sql
SELECT endDate FROM TRIPS; -- shows three records
SELECT date(endDate) FROM TRIPS; -- shows two records
```
Copy Example:
To accept the invitation:
POST /accept-invitation username=<username>
password=<password> email=you@domain.tld
secret=8c6b5719-7b1c-471c-bdea-7807b6c0866c
Allow users to accept invitations that we email to them.
TL;DR:
- I learned how to write FromHttpApiData instances, which allows me to
parse/validate data at the edges of my application; this substantially cleans
up my Handler code.
TL;DR:
- Prefer the more precise verbiage, "Accounts", to "Users"
- Add username field to Trip instead of relying on session.username
- Ensure that decodeRole can JD.fail for invalid inputs
- Define print.css with media=print type (note: could've been handled with
@media queries)
- Define printPage port to interop with window.print() JS function
- Support UI.wrapNoPrint to wrap components with a the no-print CSS
TL;DR:
- Ensure Types.TripPK in Types.hs uses Calendar.Day for startDate
- Prefer verbiage "GotCreateTrip" to "CreatedTrip"
- Extend Utils.deleteWithCredentials to accept a body parameter
- Support a delete button in the UI
Problem: When I'm working on a feature, I save my code, and elm-live reloads the
browser. This is usually good, except that the application state is
reinitialized, which usually means that the view changes.
I defined two state configurations, and I expect to define more:
- prod: The initial state for the application
- userHome: The state I'd like to use when developing a feature for the UserHome
page.
Idea: For more ad-hoc configurations, I can store the application state in
LocalStorage and restore it in between page refreshes.
*sigh* ... spent way too much time encoding/decoding date types...
I need my database, server, client, and JSON need to agree on types.
TL;DR:
- Add CSS for elm/datepicker library
- Create Common.allErrors to display UI errors
- Prefer Data.Time.Calendar.Day instead of newtype Date wrapper around Text
Client-side, I'm not exposing the role option to users. Server-side, I'm
asserting that requests to create Manager and Admin accounts are attempted by
users with a session tied to an admin account.
Toggle b/w logging in or signing up.
TL;DR:
- From my previous submission's feedback, disallow users from signing themselves
up as admins, managers; I just removed the UI element altogether, even though
the server still support this (TODO)
@dmjio says (probably correctly) that it's best to just serve the client from
the server and circumvent CORS issues altogether.
One day I will set that up. For now, this works... *sigh*
