Add Button on UC Davis UI to call to CSUS Application

[DerekMaggio]

@qjhart & @jrmerz

We are working on integrating our application with yours.

In fin-example-repository on page that views an image that you want to be able to run the OCR on can you put a button that makes an OPTION request to localhost:5000://tesseract with a payload of

{
    user: 'username',
    image_path: 'path/to/image'
}

Here is an example

{
    user: 'csus',
    image_path : "/collection/example_3-catalogs/catalogs/199/media/images/199-3",
}

[qjhart]

@jrmerz, I think this is something we can put on sandbox, Guys, let's make that a public DAMs, so we can use it here too.

[DerekMaggio]

@jrmerz actually don’t add the button just yet. I want to run a design idea by you Tuesday that may change what the link of the button is

On Nov 9, 2018, at 9:37 AM, Quinn Hart notifications@github.com wrote:

@jrmerz, I think this is something we can put on sandbox, Guys, let's make that a public DAMs, so we can use it here too.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

[jrmerz]

I'd prefer the button to just be an anchor tag with href link. So a HTTP GET request with normal URL parameters.

How come we are passing a username?

[DerekMaggio]

After some changes the button would make a GET request to http://localhost:5000/init with a query string of the path to the image and username.

@jrmerz I don't know how else we would pass what user is going to be using our application. Would we do this with a cookie?

[jrmerz]

I'm assuming here you are passing a username to understand the identity of who is making a mark? If that is the case, you can't trust a username provided via a url parameter. Otherwise what is to stop me from making marks as quinn? I would just need to visit the url with ?username=quinn and I'm in.

You have two options here. The simple option is to:

• Share the JWT token via the url
• Pass the JWT token to your server (which shares the JWT secret with your DAMS) and verify it's valid.
• Create a session token for the user (or just validate the JWT on every post).

Issue with this is we can't share a JWT secret with your environment.

Really you should look authenticate users against your own dams, the one you are writing results to.

[DerekMaggio]

So keep a log of verified users that we authenticate against?

How would we get the user information securely the first time to create the user profile on our DAMS?

It seems that the best way to do it would be to have one login that is authenticated by your system and somehow your system tells us that the user is a valid user and shares the username so we can create a data entry under the name for the picture they are working on.

Also, our DAMS would be on your system's LDP correct? We wouldn't need have our own instance of an LDP correct?

Would our user data storage be a container on the LDP? I have been working on creating this infrastructure and have been struggling a little bit.

[jrmerz]

Accounts/identities will be for the Sac State application domain. To share identities between UCD and Sac State applications would require the UCD DAMS to support a service like Oauth. For several reasons we have no plans to be a Oauth Identity Provider. Even if the UCD DAMS had an Oauth service, the UCD login is based UCD CAS credentials which limits the domain of users who could use the Sac State application (even the developers couldn't use it :) ).

As we discussed on the sprint day, users will authenticate via the Sac State DAMS. Only publicly available resources will be requested from the UCD DAMS, so no authentication is required on the UCD side of things.

Here is the diagram for review:

Let me know if this helps our if you need further clarity.

[DerekMaggio]

That makes so much more sense! Thank you @jrmerz.