search

PhilanthropyDataCommons / auth

PDC related extensions that were made for the keycloak auth service
1 stars 1 forks source link

Add a starting point for a theme #14

Closed bickelj closed 1 year ago

bickelj commented 1 year ago

This copies CSS from the existing Keyloak theme named keycloak. From here, the style.css stylesheet can be modified to PDC's needs. The login.ftl is in the way unless we want to change the page elements.

Issue #7 Theme the user-facing Keycloak pages

bickelj commented 1 year ago

Screenshots of pages using a jar built from 3ad93f9 can be seen at https://github.com/PhilanthropyDataCommons/auth/issues/7#issuecomment-1497631202

bickelj commented 1 year ago

I think this is good enough for a while. Before committing any more images or fonts, though, I would rather we add a build step to data-viewer that publishes binaries somewhere. The same is true for these auth subdirectories, they should get published to Maven Central, for example.

reefdog commented 1 year ago

I would rather we add a build step to data-viewer that publishes binaries somewhere.

We do have a build step, but the output is delivered to Netlify's CDN to host statically and not otherwise preserved. If we're hoping to preserve this output somewhere that's accessible besides through Netlify CDN URLs (i.e., the public website), I think we could add another build step to the CD that published to an additional destination. Do you have a destination in mind or would we need to architect this?

I assume one requirement is that this version of the publishing step provide consistent (non-hashed) filenames, so that other build/publishing pipelines can reference them reliably? And of course, that they are accessible to these other pipelines?

jasonaowen commented 1 year ago

The data-viewer is a hosted web application; it should not produce assets to be reused by other applications, and nor should its hosted assets be referenced here. More broadly, we should avoid coupling between Keycloak and the data-viewer. If there were more assets we wanted to reuse across multiple repos, then we would want to extract a dependency that this package and the data-viewer would both depend on.

There are two sets of assets we're talking about here: fonts, and the PDC logo.

The fonts are not original to the PDC; they come from the Google Web Fonts. There is nothing special about the versions hosted at pilot.pdco; their filenames were produced by webpack, and they include hashes to aid in cache and cache invalidation. Not referring to them directly was the right choice!

This package should also depend on an upstream package. The WebJars project repackages NPM packages into jar files, and it has @fontsource/source-sans-pro. We should depend on that, rather than committing third-party binary files to this repo. My gradle is a little rusty, so I'm not sure if it should produce a fat jar or if there should be a copy step to extract the resources from that dependency; @bickelj, do you have an opinion there?

The logo is not so concerning to me. Duplicating it across repos isn't ideal, but it's going to change so rarely, and there's only one, so I'm fine with it.

So, yes, I'd love for us to remove the font files from this repo and depend on an upstream package.