Showed the data access diagram to some users and they read the diagram as arrows from one box were leading to the others. We need a way to show that the consumers are at the right side of the arrows in each box.

Implement a sandbox OpenID Connect identity provider for local development so that parts of the web site that require login function without connecting to the real Amazon Cognito identity provider.

1. Add node-oidc-provider as a dev dependency.
2. Create an Architect plugin in the src/plugins directory and add it to the @plugins section of app.arc.
3. In the plugin, add a sandbox.start hook that initializes a node-oidc-provider Provider and runs it on an open port. It can have a single, hardcoded user account.
4. In the plugin, add a set.env hook which populates an env variable with the OIDC .well-known/openid-configuration metadata: from the sandbox identity provider if running in sandbox mode, or from the Cognito identity provider if running in production mode.
5. Update app/routes/__auth to configure node-openid-client using the OIDC metadata returned by the plugin.

This will close #91.

Add Launchpad OIDC provider as a "social auth" provider in our Cognito user pool. I wrote to the Launchpad POC at GSFC on January 13 requesting instructions for generating OIDC client credentials for our application.

CC @cbgithubb

Create a User Settings or Account Preferences page. Currently the Client Credentials form (/client_credentials) is linked from the home page, but it should be linked from the User Settings or Account Preferences page.

Perhaps use the side nav layout similar to /docs or /missions.

We have a single live Kafka development broker. It needs a FQDN and an automatically renewed SSL certificate.

This issue has two parts:

1. Domain name: get kafka0.dev.gcn.gsfc.nasa.gov assigned to development Kafka broker.
2. Set up the instance that is hosting the Kafka broker to get an automatically renewed SSL certificate that is trusted by the default CA bundle. Let's Encrypt?

CC @cbgithubb

2-level tree of checkboxes for selection of GCN notice types.

Please remove any notice type with "internal" in name from QuickStart widget.

The client code samples currently include hop-client, adc-streaming, and confluent-kafka-python. However, all three of these currently require unreleased versions.

For now, replace the code samples with gcn-kafka-python and gcn-kafka-js, which are fully supported with released versions.

We can add back support for the other libraries at a later date.

Create an entry for GCN on the HEASARC feedback form, and then add the link to the footer.

Add a little primer on "what is kafka". This probably goes partly on the main page and partly in the documentation.

Originally posted by @jracusin in #56 (comment)

The footer needs to be customized with links to NASA, GSFC, and ASD.

Definition of Done

1. Design a footer using react-uswds widgets. See react-uswds GitHub project page and documentation.
2. Customize the footer in the page template in the file app/root.tsx.

Current Placeholder

The new GCN Circulars page is very obviously a placeholder and does not look polished enough to be public yet. Ultimately, it will need to reach feature parity with the old GCN Circulars archive, but before we get to that point it needs a certain je ne sais quoi to call it finished.

Some things that might be missing:

• Prominent link to archive
• Explanation of what GCN Circulars are
• Links to writing guide, code of conduct
• An example circular
• Maybe a tiny bit of dynamic content: link to most recent circular (that might be a task for Victor or Leo)

Add NASA branding and legal text to the Cognito hosted UI. This is a stop-gap measure until #11 can be made to work.

Add a change password form under user preferences. It should only be displayed for users who have signed on with username and password, and not for users that have signed in with federated identities from LaunchPad, Facebook, or Google.

It should exist as a new page under the user menu and side nav.

We can use the Cognito ChangePassword API call.

The domain has to appear in the client sample code in the docs section. It should be parametrized by the hostname of the web site:

Write a Contributing guide with instructions for cloning the repository, setting it up for development, and making a pull request. This should be a Markdown page in the web site, but there should be a link from the README file.

Any one end user may log in with several different identity providers, sending us a different OIDC iss and sub claim each time. Since there's no way to tell that they all represent the same end user, we should maintain in our database a record of the email address that we got the last time for the given iss and sub, and ask the user if they want to sign in the same way as before.

Example:

1. Alice logs in the first time using Facebook. We receive the claims {"iss": "facebook", "sub": "12345", "email": "[email protected]"}.
2. Alice logs in the second time using Google. We receive the claims {"iss": google", "sub": "67890", "email": "[email protected]"}.
3. Our application should remembers that someone has logged in before with the same email address and send back to the user: We see that you previously logged in to GCN with the email address "[email protected]" through Facebook. Would you like to log in to that account?

Create customized sign-in, sign-up, and sign-out forms so that we don't have to use the hideous Cognito hosted UI (see #10).

Note that this might require some upstream work in Remix itself (see remix-run/remix#806).

We need a human being that people can contact with accessibility questions according to ICT 603.3.

Write a Quick Start guide with instructions for receiving alerts: signing up for GCN, creating a Client Credential, and configuring confluent-kafka-python.

Create a home page (app/index.md, app/index.tsx, or app/index.mdx) with some content explaining what General Coordinates Network is, and how it is related to the legacy Gamma-ray Coordinates Network.

Add a documentation section on science results enabled by GCN and motivation for GCN. This could end up being part of the same page as #59.

• Adapt text from https://gcn.gsfc.nasa.gov/motivation.html (which hasn't been updated since 2003)
• Discuss Fermi and Swift era discoveries
• Discuss GWs and GW170817

Design a sign-up/log-in/account info widget for the page header. The current design, shown in the attached screen shot, only provides a Log In link and not a Sign Up link.

Definition of "Done"

1. Research best practices by studying account widgets on other USWDS powered sites .
2. Ask about best practices in the USWDS public Slack channel.
3. Implement the design using react-uswds components in the page template in the file app/root.tsx.

Current placeholder design

GCN Classic uses an unencrypted, unsigned TCP protocol with only host IP authentication. It is vulnerable to IP address spoofing attacks. We need a secure connection between GCN Classic (running on a physical machine at GSFC) and our gcn-to-kafka bridge server (running in AWS).

Do a trade study of methods for establishing a secure point-to-point connection between an on-prem machine at GSFC and a compute resource (EC2 instance or ECS container) in AWS. Some options:

1. SSH tunnel only
2. VPN only
3. SSH + VPN
4. SSH + VPC route table
5. ...other methods?

Provide a theming consistent with USWDS for a partially selected checkbox. (Extra credit: contribute upstream to USWDS.)

Make instructions for receiving, submitting, and composing GCN Circulars by adapting content from gcn.gsfc.nasa.gov, converting to Markdown, editing for style and grammar, and migrating to new site.

Add a documentation page on the history of GCN:

• Adapt text from upon https://gcn.gsfc.nasa.gov/brief_describe.html
• Ask Scott and some GRB old-timers for good stories and anecdotes about the days of pagers
• Discuss the new GCN, the debut of Kafka, relationship with VRO and SCiMMA

Required for Section 508 compliance

The attached slides represent the suggested page content and layout of the minimum viable product version of the new gcn website.

mvp_accountmanagement.pptx
mvp_changelog.pptx
mvp_circulars.pptx
mvp_documentation_about.pptx
mvp_documentation_add_mission.pptx
mvp_documentation_circulars_receive.pptx
mvp_documentation_circulars_submit.pptx
mvp_documentation_faq.pptx
mvp_documentation_landing.pptx
mvp_documentation_notices_receive.pptx
mvp_documentation_notices_submit.pptx
mvp_landing.pptx
mvp_mission_landing.pptx
mvp_notices.pptx
mvp_signin.pptx

According to https://cset.nasa.gov/specification/nasa-it-consent-banner-nasa-spec-2669-version-1-0/, we need to show the user some legal text before they log in. There is no way to add regulatory text to the Cognito hosted UI, so we'll have to show it to the user before we redirect them to Cognito.

The LOC level documentation is important to show that we are complying with NASA identity proofing requirements. It will also allow us to justify when we do require MFA and when we do not.

Can this be public? If so, it could be part of our developer documentation. If not, then we should have a separate private repo for this and other moderate information (i.e., not secret stuff like client credentials, but FISMA Moderate details of security, hosting, deployment).

Add FAQ explaining what this warning means when running the listener code. It means that no messages have ever been sent to those topics before.

For example:
b'Subscribed topic not available: gcn.classic.text.AGILE_GRB_GROUND: Broker: Unknown topic or partition'

This is the original concept draft storyboard from October 2021. This should be regarded as a historical reference, but should not be used as a working draft.
GCN_Storyboard_First_Draft.pptx

Add a live ticker showing the most recent GCN notices.

Currently, the OIDC state and code verifier (which are used to secure the login process against CSRF) are stored in the same long-lived cookie that keeps track of the user's session. It should be stored in a separate short-lived cookie that expires in just a couple minutes.

No logging output on the terminal or in the browser. Just... nothing happens.

Just wondering.

Also, we're going to put together a users page for remix and I'd love to include NASA on that page if possible.

Fill in the Missions tab with a list of all current and past participating facilities, with vital statistics such as:

• Short description
• Images and logos
• Link to NSSDC page?
• Dates of operation
• Instruments
• Bandpasses
• Notice types
• Links to mission and instrument home pages

The interface for creating and managing client credentials currently consists of a table of existing credentials, a button that raises a modal to create a new credential, and a button to delete that raises a modal to confirm. There are a few UX problems with this:

• When we give the user the new client ID and client secret, we should also display boilerplate code (based on the code in the docs) for a selection of Kafka clients with the credentials filled in. There is no place in the current interface to do this.
• Modals are not the most accessible way to present a form.
• The current implementation of the modals does not provide indication of progress because it uses client side scripting rather than React routing and Remix form handling.
• We think that we need to add a CAPTCHA step.

Rebuild the client credentials UX using different USWDS components other than modals. Two nice options:

• Step indicator
• Process list

Current screen shots

Complete the main Documentation landing page. Currently it is a placeholder. Suggested content:

• A brief description of GCN
• Verbal description of what's in the documentation, links to the most important pages

The client credential vending machine should fall back to a no-op implementation where it updates the database but does not actually create or destroy client credentials.

Please use full names of old mission:
XTE -> RXTE
HETE -> HETE-2
SAX -> BeppoSAX
Also add "(historical)" afterwards, so people know why they're there.

According to the OpenID Connect spec:

The sub (subject) and iss (issuer) Claims, used together, are the only Claims that an RP can rely upon as a stable identifier for the End-User, since the sub Claim MUST be locally unique and never reassigned within the Issuer for a particular End-User, as described in Section 2. Therefore, the only guaranteed unique identifier for a given End-User is the combination of the iss Claim and the sub Claim.

We can't rely on sub alone to identify a user.

Complete all of the remaining missions pages. No 404 errors.

The Swift mission page should use the same machine-readble enum names as we use for Kafka topic names.

I am not sure how to do this for Swift because some of the notice types that are currently listed (like XRT_PosNack) seem to have no matching enum name.

See #67, https://gcn.gsfc.nasa.gov/filtering.html, and https://github.com/lpsinger/pygcn/blob/main/gcn/notice_types.py.