Polishing some aspects of the application

[rayoz12]

Goals of PR:

1. Move Field management back to OpenHarvest

2. Implement viewing a farmer's details of their fields

3. Improve the Map Experience by replacing Latlng text fields with a new point selector component

4. Enable JWT based Authentication to OpenHarvest as a standard.

• There are a few reasons for this:
• Integrations are unable to use the IBMid OAuth, OpenID authentication flow without having to open a browser and authenticate through OpenHarvest
• We will need to support API Key based authentication to make it easier to interface with OpenHarvest from Integrations. Part of an overall strategy of making the Integration Experience as easy and slick as it can be.
• We are currently using session based authentication which can't be scaled to multiple services. If we ever need OpenHarvest authentication in another OpenHarvest service it will make things difficult.
  • We can of course use a database to store session state but it feels like too much for just authentication.

Authentication Flow

sequenceDiagram
    participant client as Client (Web App)
    participant api as OpenHarvest API
    participant ibmid as IBMId
    client->>api: /auth/login
    api-->>client: 302 Redirect to IBMId for Auth
    client->>ibmid: Authenticates using
    ibmid->>api: "/auth/sso/callback": With user details 
    api->client: Updates session with user details
    api->client: Generates a JWT Token for user
    api->>client: "/?token=..." attaches token to a http param
    opt Get User Details
        client->>api: Req. for User details: Token in "Authorization" header
        api->>client: User Details
    end
    opt API request
        client->>api: Call OpenHarvest API: Token in "Authorization" header
    end

[vikasjagtap]

(Just looking at the auth flow digram): I think token should be sent in the header, we should introduce at least two custom headers X-OPENHARVEST-TOKEN and X-OPENHARVEST-ORG, the token might be able to hold organisation of the user, but that will impact the user's login flow at the frontend, so we should have both if it makes more flexible.

[rayoz12]

(Just looking at the auth flow digram): I think token should be sent in the header, we should introduce at least two custom headers X-OPENHARVEST-TOKEN and X-OPENHARVEST-ORG, the token might be able to hold organisation of the user, but that will impact the user's login flow at the frontend, so we should have both if it makes more flexible.

I agree on sending both in the header. For the token I'm using the standard Authorization header as a bearer token. What do you mean by impacting the user's login flow?

What happens right now is that the user is on boarded (with their selected org) and the web app calls the /me endpoint to get the updated user details. Since the payload in both the token and this endpoint is the same we can just use what that endpoint returns from then on.

Edit: Updated the Diagram above to show what I mean.

[rayoz12]

Merged so @JonathanScialpi can start his work