Change Details

SDS 2.5.5 Hypothesis: > If we build a service for instrument configuration, we can deliver a prototype that is flexible enough to scale in order to integrate with our future experimentation flagging solution. Implementation tasks TKTK

SDS 2.5.5 Hypothesis: > If we build a service for instrument configuration, we can deliver a prototype that is flexible enough to scale in order to integrate with our future experimentation flagging solution. Tickets: - Development Environment Setup: - Create gitlab repos - Wire CI - Create helm charts - Setup documentation - Create Dev Docker Env(s) - Deployment for each app and extension - Setup monitoring and dashboards - Backend: - Wikimedia’s service-scaffold-node - This may be deprecated by Thomas Chin’s work in this area on the Not Service Runner project - Authentication - openid-client to authenticate users using CAS-SSO - We propose authenticating and authorizing users using OpenID Connect, implemented in openid-client, and CAS-SSO as the OpenID Connect Issuer. Because the app will not make API requests to any third parties, we propose implementing the Authorization Code Flow and storing the user identity, session ID, and an HMAC in an httpOnly session cookie (herein “the session cookie”). - Security review of openid-client - Has it already been security reviewed? - Request new LDAP group for users of the app - Implement Authorization Code Flow in app - Implement post-auth flow LDAP group check - Implement generic Double Submit Cookie methods for use when displaying forms - Generate - Validate - Routing - see Instrument Configurator – Design Document - All routes require authentication and authorization except where noted otherwise. - Logging - mwbot to add entries to the SAL - Datastore - knex or pg to query the Data Products PostgreSQL cluster - Setup DB - Data Model - Access from - Backend API - Frontend Client - Frontend: - Implement views based on wireframes - Login - List view - User - Create/Update/Expire - Validation - express-validator to validate user input - MediaWiki Extension - The Metrics Platform MediaWiki extension will implement a hook handler for the ESC hook. The hook handler will fetch the instrument configuration from the app (via the GET /api/v1/instruments route), adapt the response to match the expected format, and return the result. - Deploy the stub as soon as possible(important avoid two week delay) - Approval process for deploying everywhere? - Hook handler for the hook that EventStreamConfigs will use - Fetch instrument config from Backend API - EventStreamConfiguration - We will update ESC to be able to fetch stream configurations from other sources via a hook. ESC will be responsible for merging the stream configurations. - No deep-merge multiple stream configurations - Static configuration gets highest priority - Caching - Instrument Configurator – Design Document

SDS 2.5.5 Hypothesis: > If we build a service for instrument configuration, we can deliver a prototype that is flexible enough to scale in order to integrate with our future experimentation flagging solution. Implementation tasks TKTKTickets: - Development Environment Setup: - Create gitlab repos - Wire CI - Create helm charts - Setup documentation - Create Dev Docker Env(s) - Deployment for each app and extension - Setup monitoring and dashboards - Backend: - Wikimedia’s service-scaffold-node - This may be deprecated by Thomas Chin’s work in this area on the Not Service Runner project - Authentication - openid-client to authenticate users using CAS-SSO - We propose authenticating and authorizing users using OpenID Connect, implemented in openid-client, and CAS-SSO as the OpenID Connect Issuer. Because the app will not make API requests to any third parties, we propose implementing the Authorization Code Flow and storing the user identity, session ID, and an HMAC in an httpOnly session cookie (herein “the session cookie”). - Security review of openid-client - Has it already been security reviewed? - Request new LDAP group for users of the app - Implement Authorization Code Flow in app - Implement post-auth flow LDAP group check - Implement generic Double Submit Cookie methods for use when displaying forms - Generate - Validate - Routing - see Instrument Configurator – Design Document - All routes require authentication and authorization except where noted otherwise. - Logging - mwbot to add entries to the SAL - Datastore - knex or pg to query the Data Products PostgreSQL cluster - Setup DB - Data Model - Access from - Backend API - Frontend Client - Frontend: - Implement views based on wireframes - Login - List view - User - Create/Update/Expire - Validation - express-validator to validate user input - MediaWiki Extension - The Metrics Platform MediaWiki extension will implement a hook handler for the ESC hook. The hook handler will fetch the instrument configuration from the app (via the GET /api/v1/instruments route), adapt the response to match the expected format, and return the result. - Deploy the stub as soon as possible(important avoid two week delay) - Approval process for deploying everywhere? - Hook handler for the hook that EventStreamConfigs will use - Fetch instrument config from Backend API - EventStreamConfiguration - We will update ESC to be able to fetch stream configurations from other sources via a hook. ESC will be responsible for merging the stream configurations. - No deep-merge multiple stream configurations - Static configuration gets highest priority - Caching - Instrument Configurator – Design Document