spec(wikibase-integration): add kiro spec#136
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds three new specification documents defining the Wikibase REST API integration: a design overview, formal requirements, and a task-based implementation plan, including proposed backend/ frontend interfaces, data models, caching, multi-instance support, error handling, and validation flows. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Frontend UI (PropertySelector/ValidationDisplay)
participant Composables (useWikibaseApi/useLiveValidation)
participant Backend API
participant Services (Api/Cache/Config)
participant Wikibase REST
User->>Frontend UI (PropertySelector/ValidationDisplay): Select instance/property, input value
Frontend UI (PropertySelector/ValidationDisplay)->>Composables (useWikibaseApi/useLiveValidation): search/get property, constraints, validate
Composables (useWikibaseApi/useLiveValidation)->>Backend API: /properties, /constraints, /items
Backend API->>Services (Api/Cache/Config): resolve instance, check cache, fetch/update
Services (Api/Cache/Config)->>Wikibase REST: GET search/property/constraints
Wikibase REST-->>Services (Api/Cache/Config): responses
Services (Api/Cache/Config)-->>Backend API: data (with cache flags)
Backend API-->>Composables (useWikibaseApi/useLiveValidation): ApiResponse
Composables (useWikibaseApi/useLiveValidation)-->>Frontend UI (PropertySelector/ValidationDisplay): data/validation result
Frontend UI (PropertySelector/ValidationDisplay)-->>User: live data, constraint feedback
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (18)
.kiro/specs/wikibase-rest-api-integration/requirements.md (4)
15-19: Expand Requirement 1 to cover language and stale-data UXAdd explicit acceptance criteria for language fallback, caching freshness indicator, and user-consumable error messages. This reduces ambiguity for i18n and offline scenarios.
#### Acceptance Criteria 1. WHEN a user selects a Wikibase instance THEN the system SHALL establish a connection using the @wmde/wikibase-rest-api package 2. WHEN a user searches for properties THEN the system SHALL retrieve property information including labels, descriptions, and data types from the live Wikibase instance 3. WHEN property data is fetched THEN the system SHALL display the most current information available from the Wikibase REST API - 4. IF the Wikibase instance is unavailable THEN the system SHALL display an appropriate error message and fallback to cached data if available + 4. IF the Wikibase instance is unavailable THEN the system SHALL display a localized error message and fallback to cached data if available + 5. WHEN language-specific labels/descriptions are unavailable THEN the system SHALL use a defined fallback language order and indicate the language shown + 6. WHEN showing cached data THEN the system SHALL indicate staleness (e.g., “cached from 10m ago”) and provide a manual refresh control
37-41: Specify cache TTL, ETag support, and request dedupingMake caching measurable and resilient: define TTLs, entity-versioning, and coalescing identical in-flight requests to avoid thundering herd near rate-limits.
#### Acceptance Criteria - 1. WHEN API requests are made THEN the system SHALL implement appropriate caching mechanisms to reduce redundant calls + 1. WHEN API requests are made THEN the system SHALL implement appropriate caching mechanisms (with configurable TTLs per resource) to reduce redundant calls 2. WHEN cached data exists and is fresh THEN the system SHALL use cached responses instead of making new API calls - 3. WHEN cache expires or is invalidated THEN the system SHALL fetch fresh data from the Wikibase REST API - 4. IF API rate limits are approached THEN the system SHALL implement backoff strategies and queue management + 3. WHEN cache expires or is invalidated THEN the system SHALL fetch fresh data from the Wikibase REST API and update ETag/Last-Modified metadata + 4. IF API rate limits are approached THEN the system SHALL implement exponential backoff, respect Retry-After headers, and deduplicate identical in-flight requests + 5. Cache keys SHALL include instanceId, resource id, and language to prevent cross-instance/language leakage
60-64: Clarify offline/limited-data validation UX and telemetryWhen validating with cached/incomplete data, define explicit UI indicators and telemetry for operators to monitor degraded behavior.
#### Acceptance Criteria 1. WHEN editing schema mappings THEN the system SHALL continuously validate against live constraint data 2. WHEN validation errors occur THEN the system SHALL highlight problematic mappings with specific error descriptions 3. WHEN constraints are satisfied THEN the system SHALL provide positive feedback indicating valid mappings - 4. IF constraint data cannot be fetched THEN the system SHALL indicate when validation is based on cached or incomplete information + 4. IF constraint data cannot be fetched THEN the system SHALL indicate when validation is based on cached or incomplete information (with explicit badges/tooltips), and emit telemetry events for monitoring
11-11: Style/consistency nit: capitalize product name and termsUse “Wikibase Schema Editor” consistently; also prefer “Wikibase” capitalized and “real-time” (hyphenated) when used adjectivally.
-**User Story:** As a data analyst using the wikibase schema editor, I want to fetch live property information... +**User Story:** As a data analyst using the Wikibase Schema Editor, I want to fetch live property information....kiro/specs/wikibase-rest-api-integration/design.md (8)
13-26: Clarify cache responsibilities across backend vs frontendDiagram shows both a backend cache layer and “Browser Storage/Memory Cache.” Define which data is cached where, eviction policies, and how coherence is maintained to avoid stale divergences.
graph TB - C --> F[Browser Storage/Memory Cache] + C[Cache Layer (server)] -->|HTTP cache headers (ETag/Max-Age)| A[Frontend Schema Editor] + subgraph Frontend + F[Optional client cache (in-memory/session)] + end + A -->|stale-while-revalidate| B
50-70: Augment API service with pagination, language, and cancellationInclude AbortSignal/cancellation and explicit language and paging parameters to avoid UI deadlocks and manage backpressure.
interface WikibaseApiService { // Client management createClient(instanceConfig: WikibaseInstanceConfig): WikibaseClient getClient(instanceId: string): WikibaseClient // Property operations - searchProperties(instanceId: string, query: string, options?: SearchOptions): Promise<PropertySearchResult[]> + searchProperties(instanceId: string, query: string, options?: SearchOptions & { limit?: number; offset?: number; language?: string; signal?: AbortSignal }): Promise<PropertySearchResult[]> - getProperty(instanceId: string, propertyId: string): Promise<PropertyDetails> - getPropertyConstraints(instanceId: string, propertyId: string): Promise<PropertyConstraint[]> + getProperty(instanceId: string, propertyId: string, opts?: { language?: string; signal?: AbortSignal }): Promise<PropertyDetails> + getPropertyConstraints(instanceId: string, propertyId: string, opts?: { language?: string; signal?: AbortSignal }): Promise<PropertyConstraint[]> // Item operations - searchItems(instanceId: string, query: string, options?: SearchOptions): Promise<ItemSearchResult[]> - getItem(instanceId: string, itemId: string): Promise<ItemDetails> + searchItems(instanceId: string, query: string, options?: SearchOptions & { limit?: number; offset?: number; language?: string; signal?: AbortSignal }): Promise<ItemSearchResult[]> + getItem(instanceId: string, itemId: string, opts?: { language?: string; signal?: AbortSignal }): Promise<ItemDetails> // Data type operations - getPropertyDataTypes(instanceId: string): Promise<PropertyDataTypeMap> + getPropertyDataTypes(instanceId: string, opts?: { signal?: AbortSignal }): Promise<PropertyDataTypeMap> }
75-84: Cache service ergonomics: add getOrSet and metadata supportCaching constraints and properties benefits from a getOrSet helper and storing metadata (ETag, lastFetched, language).
interface WikibaseCacheService { get<T>(key: string): Promise<T | null> set<T>(key: string, value: T, ttl?: number): Promise<void> invalidate(pattern: string): Promise<void> + getOrSet<T>(key: string, loader: () => Promise<T>, ttl?: number): Promise<T> // Specialized cache methods - cachePropertyData(instanceId: string, propertyId: string, data: PropertyDetails): Promise<void> - getCachedPropertyData(instanceId: string, propertyId: string): Promise<PropertyDetails | null> + cachePropertyData(instanceId: string, propertyId: string, data: PropertyDetails, opts?: { language?: string; etag?: string; fetchedAt?: string; ttl?: number }): Promise<void> + getCachedPropertyData(instanceId: string, propertyId: string, opts?: { language?: string }): Promise<PropertyDetails | null> }
219-225: Enrich PropertyConstraint for traceabilityAdd a stable id/source and optional severity to support reporting and deduplication.
interface PropertyConstraint { + id?: string type: string parameters: Record<string, any> description?: string violationMessage?: string + severity?: 'error' | 'warning' + sourceStatementId?: string }
256-269: API envelopes: include cache and localization metadataExpose language, ETag, and freshness to the client to render correct UI badges and enable conditional requests.
interface ApiResponse<T> { data: T cached: boolean timestamp: string instanceId: string + language?: string + etag?: string + maxAgeSeconds?: number } interface SearchResponse<T> { results: T[] totalCount: number hasMore: boolean query: string + language?: string }
284-305: Operationalize retry using Retry-After and jitterMake the retry policy explicit and resilient to coordinated retries.
const handleApiError = (error: WikibaseError) => { switch (error.code) { case 'RATE_LIMITED': - return scheduleRetry(error) + // Use server-provided Retry-After where available; else exponential backoff + jitter. + return scheduleRetry(error, { useRetryAfter: true, baseMs: 500, factor: 2, jitter: true, maxMs: 30000 }) case 'NETWORK_ERROR': return useCachedData(error) case 'INVALID_PROPERTY': return showValidationError(error) default: return showGenericError(error) } }
275-279: Nit: hyphenate compound adjectives (“rate-limiting”)Minor grammar fix for clarity in documentation.
-1. **Network Errors**: Connection failures, timeouts, rate limiting +1. **Network Errors**: Connection failures, timeouts, rate-limiting
340-357: Testing snippet should reference concrete class or factoryThe example uses new WikibaseApiService() but only an interface is defined here. Clarify by referencing an implementation or factory in examples to avoid confusion.
-const service = new WikibaseApiService() +const service = createWikibaseApiService(/* deps */).kiro/specs/wikibase-rest-api-integration/tasks.md (6)
3-8: Add package verification and license check to setupGuard against typosquatting and ensure the client dependency exists with acceptable license.
- [ ] 1. Set up project dependencies and core types - Install @wmde/wikibase-rest-api package in backend - Create TypeScript type definitions for Wikibase data models - Set up basic error handling types and utilities + - Verify package availability and license (npm view / npm info) and pin to a vetted version - _Requirements: 1.1, 2.1, 3.1_
30-44: Include request coalescing and language-aware cache keysPrevent duplicate upstream calls and avoid cross-language cache contamination.
- [ ] 3.1 Implement cache service with TTL support - Create WikibaseCacheService with get/set/invalidate methods - Implement memory-based caching with configurable TTL - - Add cache key generation utilities for different data types + - Add cache key generation utilities for different data types (namespaced by instanceId and language) + - Implement promise-based request coalescing to deduplicate concurrent identical requests
82-103: Include cancellation and debounce in composable APIPrevent stale updates and improve UX by supporting AbortController and debounced searches.
- [ ] 6.1 Create useWikibaseApi composable with basic functionality - Implement reactive API client with instance management - - Add searchProperties and getProperty methods using backend API + - Add searchProperties and getProperty methods using backend API (with AbortController-based cancellation and debounced search) - Implement loading states and error handling
185-199: Adopt stale-while-revalidate for offline/degraded modesProvide instant results with background refresh when back online; include telemetry to observe degradations.
- [ ] 11.2 Implement graceful degradation for offline scenarios - Add offline detection and cached data fallback mechanisms - - Disable live features when API is unavailable + - Disable live features when API is unavailable and use stale-while-revalidate to refresh in background when connectivity resumes - Show appropriate user feedback for degraded functionality - Write tests for offline behavior and cache fallback
200-214: Define performance budgets and metrics collection planAdd concrete SLOs and measurement approach to make perf work actionable.
- [ ] 12.2 Add performance monitoring and metrics - - Implement API response time tracking and cache hit rate monitoring + - Implement API response time tracking and cache hit rate monitoring with defined budgets (e.g., P95 < 400ms for search; cache hit rate > 70%) - Add user-facing performance indicators and loading states - Create performance dashboard for API usage analytics
171-184: Add feature flagging and rollout plan for schema editor integrationMitigates risk by enabling gradual enablement and easy rollback.
- [ ] 10.3 Add instance selection to schema editor interface - Integrate InstanceManager component into schema editor toolbar - Add instance-specific schema validation and property suggestions - Implement schema compatibility checking across different instances + - Behind a feature flag with staged rollout and telemetry - Write integration tests for multi-instance schema editing
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
.kiro/specs/wikibase-rest-api-integration/design.md(1 hunks).kiro/specs/wikibase-rest-api-integration/requirements.md(1 hunks).kiro/specs/wikibase-rest-api-integration/tasks.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
.kiro/specs/wikibase-rest-api-integration/tasks.md
[grammar] ~4-~4: There might be a mistake here.
Context: ...Install @wmde/wikibase-rest-api package in backend - Create TypeScript type defi...
(QB_NEW_EN)
[grammar] ~30-~30: There might be a mistake here.
Context: ... - Requirements: 2.1, 2.2 - [ ] 3. Create caching layer for API responses - [ ]...
(QB_NEW_EN)
[grammar] ~31-~31: There might be a mistake here.
Context: ...ing layer for API responses - [ ] 3.1 Implement cache service with TTL support - Cr...
(QB_NEW_EN)
[grammar] ~104-~104: There might be a mistake here.
Context: ...ent - Requirements: 4.3 - [ ] 7. Create enhanced property selector component ...
(QB_NEW_EN)
[grammar] ~105-~105: There might be a mistake here.
Context: ...property selector component - [ ] 7.1 Build LivePropertySelector component with sea...
(QB_NEW_EN)
[grammar] ~149-~149: There might be a mistake here.
Context: ....2 Build LiveValidationDisplay component - Create component for displaying validati...
(QB_NEW_EN)
[grammar] ~195-~195: There might be a mistake here.
Context: ... mechanisms - Disable live features when API is unavailable - Show appropria...
(QB_NEW_EN)
[grammar] ~211-~211: There might be a mistake here.
Context: ...nce indicators and loading states - Create performance dashboard for API usage ana...
(QB_NEW_EN)
[grammar] ~213-~213: There might be a mistake here.
Context: ...collection - Requirements: 3.1, 3.2
(QB_NEW_EN)
.kiro/specs/wikibase-rest-api-integration/design.md
[grammar] ~32-~32: There might be a mistake here.
Context: ...ibase/*` endpoints for proxy and caching - Service Layer: Wikibase API service fo...
(QB_NEW_EN)
[grammar] ~33-~33: There might be a mistake here.
Context: ...r managing client instances and requests - Cache Layer: Redis-like caching for AP...
(QB_NEW_EN)
[grammar] ~34-~34: There might be a mistake here.
Context: ...ng for API responses and constraint data - Configuration: Instance management for...
(QB_NEW_EN)
[grammar] ~41-~41: There might be a mistake here.
Context: ...or**: Live property search and selection - Real-time Validation: Constraint-based...
(QB_NEW_EN)
[grammar] ~42-~42: There might be a mistake here.
Context: ...**: Constraint-based validation feedback - Instance Switcher: UI for selecting di...
(QB_NEW_EN)
[grammar] ~43-~43: There might be a mistake here.
Context: ...r selecting different Wikibase instances - Cache Management: Client-side caching ...
(QB_NEW_EN)
[uncategorized] ~275-~275: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...rrors**: Connection failures, timeouts, rate limiting 2. Authentication Errors: Invalid t...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[grammar] ~275-~275: There might be a mistake here.
Context: ...ection failures, timeouts, rate limiting 2. Authentication Errors: Invalid tokens,...
(QB_NEW_EN)
[grammar] ~276-~276: There might be a mistake here.
Context: ...ors**: Invalid tokens, permission issues 3. Validation Errors: Invalid property ID...
(QB_NEW_EN)
[grammar] ~277-~277: There might be a mistake here.
Context: ...Invalid property IDs, malformed requests 4. Cache Errors: Cache unavailability, co...
(QB_NEW_EN)
[grammar] ~278-~278: There might be a mistake here.
Context: ...rors**: Cache unavailability, corruption 5. Configuration Errors: Invalid instance...
(QB_NEW_EN)
[grammar] ~318-~318: There might be a mistake here.
Context: ...Layer**: Test API client wrapper methods - Cache Layer: Test caching logic and in...
(QB_NEW_EN)
[grammar] ~319-~319: There might be a mistake here.
Context: ...r**: Test caching logic and invalidation - Validation Logic: Test constraint vali...
(QB_NEW_EN)
[grammar] ~320-~320: There might be a mistake here.
Context: ...*: Test constraint validation algorithms - Composables: Test reactive state manag...
(QB_NEW_EN)
🔇 Additional comments (1)
.kiro/specs/wikibase-rest-api-integration/requirements.md (1)
5-5: Confirmed official NPM package “@wmde/wikibase-rest-api”
Verified that @wmde/wikibase-rest-api is the correct, officially maintained JavaScript client for the Wikibase REST API (current version 1.3.0). No changes to the spec dependency name are needed.
- Installation:
npm install @wmde/wikibase-rest-api- Supported in Node.js and browser environments
| The solution leverages the auto-generated JavaScript client library that provides type-safe access to the Wikibase REST API endpoints, including properties, items, statements, labels, descriptions, and search functionality. | ||
|
|
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Confirm the “auto-generated JS client” assumption
The design hinges on an auto-generated, type-safe REST client. Please verify the client’s availability and its API coverage to ensure the proposed interfaces align.
🌐 Web query:
What officially supported JavaScript/TypeScript client exists for the Wikibase REST API, and what endpoints does it cover (properties, items, search, constraints)?
💡 Result:
The officially supported JavaScript/TypeScript client for the Wikibase REST API is @wmde/wikibase-rest-api, an auto-generated library published by Wikimedia Deutschland (WMDE)[1]. This client is generated from the Wikibase REST API's OpenAPI specification and aims to cover the endpoints included in the official OpenAPI definition[1][7].
Supported Endpoints
According to the documentation and source information:
- Items: The client allows operations on items, including retrieval and modification (e.g.,
getItemLabelfor labels, and likely other CRUD operations as defined in the OpenAPI spec)[1][7]. - Properties: Similar support for Wikibase properties; you can retrieve and edit property information[1][7].
- Search: Search endpoints for Items and Properties are available but require Elasticsearch to be enabled on the Wikibase instance[3]. If Elasticsearch is not configured, these endpoints will return errors.
- Constraints: While Wikibase Quality Constraints can be managed via the Wikibase extension and referenced in property definitions[5], there is no explicit mention that constraint endpoints are part of the REST API itself; constraints are generally managed as part of the data model and via extensions rather than dedicated REST API endpoints. However, constraints can be imported and set up in a Wikibase via other means, often outside the direct scope of the REST API[5][2].
The precise coverage depends on the current version of the OpenAPI spec; all endpoints defined there are available in the generated client[1]. For the latest, refer to the [OpenAPI Swagger documentation][7] and the published autodocs for endpoint lists[3].
Additional Notes
- TypeScript Support: The npm package is written in JavaScript, but you can use it with TypeScript using type declarations included or generated from the OpenAPI spec[1].
- Usage Caveats: WMDE does not guarantee full functionality for the auto-generated client, so production use should be evaluated accordingly[1].
- For advanced features such as authentication, custom user agents, or configuring Elasticsearch for enhanced search, consult the Wikibase REST API docs and server configuration guidelines[3][1].
- There is a popular alternative,
wikibase-sdk, but it does not cover REST API endpoints specifically—it is principally for querying via the old Action API and SPARQL[6].
Summary Table:
| Endpoint | Officially Supported via @wmde/wikibase-rest-api | Notes |
|---|---|---|
| Items | Yes | CRUD operations, labels, descriptions, aliases, statements[1][7] |
| Properties | Yes | CRUD, labels, descriptions, aliases, datatypes |
| Search | Yes (if Elasticsearch enabled) | Requires CirrusSearch/Elasticsearch setup on instance[3] |
| Constraints | Not as standalone REST endpoint | Managed via extension; constraints as part of properties[5] |
Official Reference:
See the [@wmde/wikibase-rest-api documentation][1] and the [Wikibase REST API OpenAPI docs][7][3] for details on specific endpoints.
Citations:
- 1: https://www.npmjs.com/package/@wmde/wikibase-rest-api
- 2: https://ceur-ws.org/Vol-3262/paper1.pdf
- 3: https://doc.wikimedia.org/Wikibase/master/php/repo_rest-api_README.html
- 4: https://pypi.org/project/wikibase-rest-api-client/
- 5: https://www.mediawiki.org/wiki/Wikibase/FAQ
- 6: https://www.npmjs.com/package/wikibase-sdk
- 7: https://www.wikidata.org/wiki/Wikidata:REST_API
- 8: https://www.mediawiki.org/wiki/Wikibase/API
- 9: https://fosdem.org/schedule/xml
- 10: https://pydigger.com/pypi/wikibase-rest-api-client
Reference the @wmde/wikibase-rest-api client and clarify its endpoint coverage
The officially supported auto-generated JS/TS client for the Wikibase REST API is @wmde/wikibase-rest-api, generated from the OpenAPI spec. It provides type-safe access to:
- Items: CRUD operations (labels, descriptions, aliases, statements)
- Properties: CRUD operations (labels, descriptions, aliases, datatypes)
- Search: item/property search (requires Elasticsearch/CirrusSearch on the Wikibase instance)
Note that there is no standalone “constraints” endpoint in the REST API—constraints are managed via the Wikibase extension and aren’t exposed directly by this client.
Please update .kiro/specs/wikibase-rest-api-integration/design.md accordingly:
-The solution leverages the auto-generated JavaScript client library that provides type-safe access to the Wikibase REST API endpoints, including properties, items, statements, labels, descriptions, and search functionality.
+The solution leverages the auto-generated `@wmde/wikibase-rest-api` client (from the OpenAPI spec), which provides type-safe access to:
+ - Items (CRUD, including labels, descriptions, aliases, statements)
+ - Properties (CRUD, including labels, descriptions, aliases, datatypes)
+ - Search (item/property search; requires Elasticsearch/CirrusSearch)
+
+Note: REST API constraint endpoints are not provided by this client; constraints are managed via the Wikibase extension.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| The solution leverages the auto-generated JavaScript client library that provides type-safe access to the Wikibase REST API endpoints, including properties, items, statements, labels, descriptions, and search functionality. | |
| The solution leverages the auto-generated `@wmde/wikibase-rest-api` client (from the OpenAPI spec), which provides type-safe access to: | |
| - Items (CRUD, including labels, descriptions, aliases, statements) | |
| - Properties (CRUD, including labels, descriptions, aliases, datatypes) | |
| - Search (item/property search; requires Elasticsearch/CirrusSearch) | |
| Note: REST API constraint endpoints are not provided by this client; constraints are managed via the Wikibase extension. |
🤖 Prompt for AI Agents
.kiro/specs/wikibase-rest-api-integration/design.md around lines 7-8: update the
generic reference to the auto-generated JS client to explicitly name the
officially supported package "@wmde/wikibase-rest-api" and clarify what
endpoints it covers—state that it provides type-safe access for Items (CRUD for
labels, descriptions, aliases, statements), Properties (CRUD for labels,
descriptions, aliases, datatypes), and Search (item/property search, which
requires Elasticsearch/CirrusSearch on the Wikibase instance); also add a note
that there is no standalone "constraints" REST endpoint and constraints are
managed by the Wikibase extension and not exposed via this client.
| - **New API Routes**: `/api/wikibase/*` endpoints for proxy and caching | ||
| - **Service Layer**: Wikibase API service for managing client instances and requests | ||
| - **Cache Layer**: Redis-like caching for API responses and constraint data | ||
| - **Configuration**: Instance management for multiple Wikibase endpoints | ||
|
|
There was a problem hiding this comment.
Harden proxy endpoints: CSRF, authZ, input validation, and SSRF protections
Proxying to arbitrary instances requires:
- CSRF protection for POST/PUT endpoints (e.g., /validate)
- Input validation and allowlisting of base URLs
- Authentication/authorization on who can add instances
- Rate limiting per user/IP and per instance
- **New API Routes**: `/api/wikibase/*` endpoints for proxy and caching
+- **Security Controls**: CSRF protection on mutating routes, authZ for instance management, per-user/IP rate limits, strict URL allowlisting, SSRF protections (no private networks)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - **New API Routes**: `/api/wikibase/*` endpoints for proxy and caching | |
| - **Service Layer**: Wikibase API service for managing client instances and requests | |
| - **Cache Layer**: Redis-like caching for API responses and constraint data | |
| - **Configuration**: Instance management for multiple Wikibase endpoints | |
| - **Security Controls**: CSRF protection on mutating routes, authZ for instance management, per-user/IP rate limits, strict URL allowlisting, SSRF protections (no private networks) | |
| - **Service Layer**: Wikibase API service for managing client instances and requests | |
| - **Cache Layer**: Redis-like caching for API responses and constraint data | |
| - **Configuration**: Instance management for multiple Wikibase endpoints |
🧰 Tools
🪛 LanguageTool
[grammar] ~32-~32: There might be a mistake here.
Context: ...ibase/*` endpoints for proxy and caching - Service Layer: Wikibase API service fo...
(QB_NEW_EN)
[grammar] ~33-~33: There might be a mistake here.
Context: ...r managing client instances and requests - Cache Layer: Redis-like caching for AP...
(QB_NEW_EN)
[grammar] ~34-~34: There might be a mistake here.
Context: ...ng for API responses and constraint data - Configuration: Instance management for...
(QB_NEW_EN)
🤖 Prompt for AI Agents
In .kiro/specs/wikibase-rest-api-integration/design.md around lines 32 to 36,
the proxy endpoints section must be hardened: add CSRF protection for mutating
routes (POST/PUT/DELETE) such as /validate, implement strict input validation
and an allowlist for permitted base URLs to prevent SSRF, require authenticated
and authorized users for adding/managing instances (role checks and audit
logging), and apply rate limiting per user/IP and per target instance; update
the design to list these controls and note where they are enforced (API
gateway/middleware, service layer, and cache layer).
| #### 2. Instance Configuration Manager (`frontend/src/features/wikibase-schema/components/InstanceManager.vue`) | ||
|
|
||
| ```typescript | ||
| interface InstanceManagerProps { | ||
| currentInstanceId?: string | ||
| allowCustomInstances?: boolean | ||
| } | ||
|
|
||
| interface InstanceManagerEmits { | ||
| 'instance-changed': [instanceId: string] | ||
| 'instance-added': [instance: WikibaseInstanceConfig] | ||
| } | ||
| ``` | ||
|
|
||
| #### 3. Real-time Validation Display (`frontend/src/features/wikibase-schema/components/LiveValidationDisplay.vue`) | ||
|
|
||
| ```typescript | ||
| interface LiveValidationDisplayProps { | ||
| propertyId: string | ||
| instanceId: string | ||
| currentValue: any | ||
| showDetails?: boolean | ||
| } | ||
|
|
||
| interface ValidationResult { | ||
| isValid: boolean | ||
| violations: ConstraintViolation[] | ||
| suggestions: string[] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Type drift: ValidationResult defined twice with mismatched shape
The component-local ValidationResult lacks “warnings” present in the core type. Use a single shared model to avoid divergence.
-interface ValidationResult {
- isValid: boolean
- violations: ConstraintViolation[]
- suggestions: string[]
-}
+// Prefer importing the shared core type:
+// import type { ValidationResult } from '@/data-models/validation'
+// Do not redefine locally to avoid drift.Also applies to: 237-242
🏁 Script executed:
#!/bin/bash
echo "1. Searching for ValidationResult definitions in TS files:"
rg -n --ignore-case "interface\s+ValidationResult" --glob "*.ts"
echo
echo "2. Searching for exported ValidationResult in TS files:"
rg -n --ignore-case "export\s+interface\s+ValidationResult" --glob "*.ts"
echo
echo "3. Searching for ConstraintViolation definitions/usages:"
rg -n "ConstraintViolation" --glob "*.ts"
echo
echo "4. Looking for a data-models directory (likely contains shared types):"
fd data-models -t d
echo
echo "5. Inspecting tsconfig.json for path aliases:"
rg -n "\"paths\"" tsconfig.json || echo "No paths section found in tsconfig.json"Length of output: 1204
🏁 Script executed:
#!/bin/bash
echo "Displaying `ValidationResult` definition in shared types:"
sed -n '1,200p' frontend/src/shared/types/wikibase-schema.tsLength of output: 3811
Use Shared ValidationResult Model
Remove the locally-defined ValidationResult in your component and docs, and import the single shared type to prevent drift:
• In frontend/src/features/wikibase-schema/components/LiveValidationDisplay.vue
– Delete the local
ts interface ValidationResult { isValid: boolean violations: ConstraintViolation[] suggestions: string[] }
– Add:
```ts
import type { ValidationResult as CoreValidationResult } from '@/shared/types/wikibase-schema'
// Extend core type for component-only fields
interface ValidationResult extends CoreValidationResult {
suggestions: string[]
}
```
– Update all uses of violations to consume errors/warnings from the core model.
• In .kiro/specs/wikibase-rest-api-integration/design.md (lines 116–145 & 237–242)
– Replace the local snippet with a reference to the shared model (e.g. comment or import instruction).
This ensures one source of truth for ValidationResult and avoids mismatched shapes.
🤖 Prompt for AI Agents
In .kiro/specs/wikibase-rest-api-integration/design.md around lines 116–145 (and
also update lines 237–242), the doc shows a locally-defined ValidationResult
that diverges from the shared model; remove that local snippet and replace it
with a note that the component uses the shared type from
frontend/src/shared/types/wikibase-schema (or an import instruction), and in
frontend/src/features/wikibase-schema/components/LiveValidationDisplay.vue
delete the local ValidationResult interface, import the shared ValidationResult
type (rename on import if needed), extend it only to add component-only fields
like suggestions, and update all code in the component to use the core model
fields (errors/warnings) instead of violations so the component and docs
reference the single source of truth.
| interface WikibaseInstanceConfig { | ||
| id: string | ||
| name: string | ||
| baseUrl: string | ||
| userAgent: string | ||
| authToken?: string | ||
| isDefault?: boolean | ||
| metadata?: { | ||
| description?: string | ||
| language?: string | ||
| version?: string | ||
| } | ||
| } |
There was a problem hiding this comment.
Do not expose auth tokens in shared configs
Placing authToken on WikibaseInstanceConfig risks leaking secrets to the client. Split server-only secrets from frontend-safe configs and reference secrets opaquely.
-interface WikibaseInstanceConfig {
+// Frontend-safe config
+interface WikibaseInstanceConfig {
id: string
name: string
baseUrl: string
userAgent: string
- authToken?: string
isDefault?: boolean
metadata?: {
description?: string
language?: string
version?: string
}
}
+
+// Server-only secret representation
+interface WikibaseInstanceSecret {
+ instanceId: string
+ auth: { type: 'oauth' | 'bot' | 'none'; tokenRef: string } // tokenRef stored in secure vault/DB, never sent to client
+}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| interface WikibaseInstanceConfig { | |
| id: string | |
| name: string | |
| baseUrl: string | |
| userAgent: string | |
| authToken?: string | |
| isDefault?: boolean | |
| metadata?: { | |
| description?: string | |
| language?: string | |
| version?: string | |
| } | |
| } | |
| // Frontend-safe config | |
| interface WikibaseInstanceConfig { | |
| id: string | |
| name: string | |
| baseUrl: string | |
| userAgent: string | |
| isDefault?: boolean | |
| metadata?: { | |
| description?: string | |
| language?: string | |
| version?: string | |
| } | |
| } | |
| // Server-only secret representation | |
| interface WikibaseInstanceSecret { | |
| instanceId: string | |
| auth: { type: 'oauth' | 'bot' | 'none'; tokenRef: string } // tokenRef stored in secure vault/DB, never sent to client | |
| } |
🤖 Prompt for AI Agents
In .kiro/specs/wikibase-rest-api-integration/design.md around lines 195 to 207,
the WikibaseInstanceConfig currently includes authToken which can leak secrets
to clients; remove authToken from this frontend-safe interface and replace it
with an opaque reference (e.g. secretId or serverOnly flag). Add a separate
server-side secrets store type (e.g. WikibaseInstanceSecrets keyed by instance
id) to hold authToken and any other sensitive fields, ensure server code
resolves secrets when making authenticated requests, update any
serialization/path handlers so the public config never includes authToken, and
adjust consumers and docs to use the opaque reference and server-side secret
retrieval instead of embedding tokens in client-shared configs.
| 1. WHEN a user selects a property THEN the system SHALL fetch associated constraint information from the Wikibase REST API | ||
| 2. WHEN constraint data is retrieved THEN the system SHALL display validation rules, allowed values, and format requirements | ||
| 3. WHEN building schema mappings THEN the system SHALL validate user input against live constraint data | ||
| 4. IF constraint validation fails THEN the system SHALL provide clear feedback about which constraints are violated | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Clarify scope of constraint types and require server-side validation
Constraints vary by type (format, range, type, unique value, allowed values, etc.). Specify which are in scope and ensure enforcement exists server-side (authoritative), not just client-side.
#### Acceptance Criteria
1. WHEN a user selects a property THEN the system SHALL fetch associated constraint information from the Wikibase REST API
2. WHEN constraint data is retrieved THEN the system SHALL display validation rules, allowed values, and format requirements
- 3. WHEN building schema mappings THEN the system SHALL validate user input against live constraint data
+ 3. WHEN building schema mappings THEN the system SHALL validate user input against live constraint data on the client AND re-validate on the server before persisting
- 4. IF constraint validation fails THEN the system SHALL provide clear feedback about which constraints are violated
+ 4. IF constraint validation fails THEN the system SHALL provide clear, localized feedback about which constraints are violated
+ 5. The following constraint types SHALL be supported in v1: value type, allowed values, range (min/max), format/pattern; others SHALL be tracked for v2📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| 1. WHEN a user selects a property THEN the system SHALL fetch associated constraint information from the Wikibase REST API | |
| 2. WHEN constraint data is retrieved THEN the system SHALL display validation rules, allowed values, and format requirements | |
| 3. WHEN building schema mappings THEN the system SHALL validate user input against live constraint data | |
| 4. IF constraint validation fails THEN the system SHALL provide clear feedback about which constraints are violated | |
| #### Acceptance Criteria | |
| 1. WHEN a user selects a property THEN the system SHALL fetch associated constraint information from the Wikibase REST API | |
| 2. WHEN constraint data is retrieved THEN the system SHALL display validation rules, allowed values, and format requirements | |
| 3. WHEN building schema mappings THEN the system SHALL validate user input against live constraint data on the client AND re-validate on the server before persisting | |
| 4. IF constraint validation fails THEN the system SHALL provide clear, localized feedback about which constraints are violated | |
| 5. The following constraint types SHALL be supported in v1: value type, allowed values, range (min/max), format/pattern; others SHALL be tracked for v2 |
🤖 Prompt for AI Agents
.kiro/specs/wikibase-rest-api-integration/requirements.md around lines 26 to 30:
the requirement set is ambiguous about which constraint types are handled and
implies validation may be client-only; update the spec to explicitly enumerate
the constraint types in scope (e.g., format/regex, numeric range, datatype/type,
allowed values, uniqueness, cardinality) and mark others as out-of-scope, and
require that constraint enforcement be performed server-side as authoritative;
add acceptance criteria that the server validates incoming user input against
live Wikibase constraint data, returns clear structured error responses
identifying violated constraint IDs and human-readable messages, and include
automated integration tests and API contract details (endpoints, status codes,
error payload shape) to ensure server-side enforcement.
| 1. WHEN configuring Wikibase instances THEN the system SHALL allow specification of base URLs, authentication credentials, and instance metadata | ||
| 2. WHEN instance configuration is saved THEN the system SHALL validate connectivity and API compatibility | ||
| 3. WHEN switching between instances THEN the system SHALL maintain separate caches and configurations for each instance | ||
| 4. WHEN setting up instances THEN the system SHALL support both custom configuration and pre-defined instance lists (such as Wikidata, Wikimedia Commons, etc.) | ||
| 5. IF instance configuration is invalid THEN the system SHALL provide clear error messages and prevent system malfunction | ||
|
|
There was a problem hiding this comment.
Add security requirements for multi-instance config (secrets, SSRF, validation)
Allowing arbitrary instance URLs and tokens is high-risk. Define how secrets are stored (server-only), how base URLs are validated/allowlisted, and how connectivity checks avoid SSRF.
#### Acceptance Criteria
1. WHEN configuring Wikibase instances THEN the system SHALL allow specification of base URLs, authentication credentials, and instance metadata
- 2. WHEN instance configuration is saved THEN the system SHALL validate connectivity and API compatibility
+ 2. WHEN instance configuration is saved THEN the system SHALL validate connectivity and API compatibility without following redirects to private networks and with strict URL scheme/domain validation (no file://, localhost, or RFC1918 by default)
3. WHEN switching between instances THEN the system SHALL maintain separate caches and configurations for each instance
4. WHEN setting up instances THEN the system SHALL support both custom configuration and pre-defined instance lists (such as Wikidata, Wikimedia Commons, etc.)
- 5. IF instance configuration is invalid THEN the system SHALL provide clear error messages and prevent system malfunction
+ 5. IF instance configuration is invalid THEN the system SHALL provide clear error messages and prevent system malfunction
+ 6. Authentication credentials SHALL be stored server-side only, encrypted at rest; the frontend SHALL never receive raw tokens
+ 7. Instance base URLs SHALL be validated/allowlisted by administrators to mitigate SSRF📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| 1. WHEN configuring Wikibase instances THEN the system SHALL allow specification of base URLs, authentication credentials, and instance metadata | |
| 2. WHEN instance configuration is saved THEN the system SHALL validate connectivity and API compatibility | |
| 3. WHEN switching between instances THEN the system SHALL maintain separate caches and configurations for each instance | |
| 4. WHEN setting up instances THEN the system SHALL support both custom configuration and pre-defined instance lists (such as Wikidata, Wikimedia Commons, etc.) | |
| 5. IF instance configuration is invalid THEN the system SHALL provide clear error messages and prevent system malfunction | |
| #### Acceptance Criteria | |
| 1. WHEN configuring Wikibase instances THEN the system SHALL allow specification of base URLs, authentication credentials, and instance metadata | |
| 2. WHEN instance configuration is saved THEN the system SHALL validate connectivity and API compatibility without following redirects to private networks and with strict URL scheme/domain validation (no file://, localhost, or RFC1918 by default) | |
| 3. WHEN switching between instances THEN the system SHALL maintain separate caches and configurations for each instance | |
| 4. WHEN setting up instances THEN the system SHALL support both custom configuration and pre-defined instance lists (such as Wikidata, Wikimedia Commons, etc.) | |
| 5. IF instance configuration is invalid THEN the system SHALL provide clear error messages and prevent system malfunction | |
| 6. Authentication credentials SHALL be stored server-side only, encrypted at rest; the frontend SHALL never receive raw tokens | |
| 7. Instance base URLs SHALL be validated/allowlisted by administrators to mitigate SSRF |
🤖 Prompt for AI Agents
.kiro/specs/wikibase-rest-api-integration/requirements.md around lines 48 to 53:
add explicit security requirements for multi-instance configuration: require
that secrets (API tokens/credentials) are only stored and used on the server
side (never exposed to the browser), mandate encryption-at-rest and access
control for stored secrets, require URL validation and an allowlist for base
URLs (reject private IP ranges and loopback to prevent SSRF), ensure
connectivity checks and health probes are performed server-side using validated
URLs with redirect and timeout controls, and document token validation/rotation
and audit logging for configuration changes.
| - [ ] 4.1 Create configuration service and data models | ||
| - Implement WikibaseConfigService for managing instance configurations | ||
| - Create data models for WikibaseInstanceConfig with validation | ||
| - Add pre-defined instance configurations (Wikidata, Wikimedia Commons) | ||
| - Write unit tests for configuration validation and management | ||
| - _Requirements: 4.1, 4.2, 4.4_ | ||
|
|
||
| - [ ] 4.2 Add instance validation and connectivity testing | ||
| - Implement validateInstance method to test API connectivity | ||
| - Add health check endpoints for configured instances | ||
| - Handle authentication and authorization for different instances | ||
| - Write integration tests for instance validation | ||
| - _Requirements: 4.2, 4.5_ | ||
|
|
There was a problem hiding this comment.
Mitigate SSRF in connectivity tests and instance validation
Connectivity checks must not fetch arbitrary URLs in private networks. Validate schemes, domains, and block RFC1918 by default.
- [ ] 4.2 Add instance validation and connectivity testing
- - Implement validateInstance method to test API connectivity
+ - Implement validateInstance method to test API connectivity with SSRF safeguards (no private IPs, no file://, strict allowlist)
- Add health check endpoints for configured instances
- Handle authentication and authorization for different instances
- Write integration tests for instance validation
- _Requirements: 4.2, 4.5_📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - [ ] 4.1 Create configuration service and data models | |
| - Implement WikibaseConfigService for managing instance configurations | |
| - Create data models for WikibaseInstanceConfig with validation | |
| - Add pre-defined instance configurations (Wikidata, Wikimedia Commons) | |
| - Write unit tests for configuration validation and management | |
| - _Requirements: 4.1, 4.2, 4.4_ | |
| - [ ] 4.2 Add instance validation and connectivity testing | |
| - Implement validateInstance method to test API connectivity | |
| - Add health check endpoints for configured instances | |
| - Handle authentication and authorization for different instances | |
| - Write integration tests for instance validation | |
| - _Requirements: 4.2, 4.5_ | |
| - [ ] 4.2 Add instance validation and connectivity testing | |
| - Implement validateInstance method to test API connectivity with SSRF safeguards (no private IPs, no file://, strict allowlist) | |
| - Add health check endpoints for configured instances | |
| - Handle authentication and authorization for different instances | |
| - Write integration tests for instance validation | |
| - _Requirements: 4.2, 4.5_ |
🤖 Prompt for AI Agents
.kiro/specs/wikibase-rest-api-integration/tasks.md around lines 46 to 59:
connectivity checks currently allow fetching arbitrary URLs which can enable
SSRF; update validateInstance/connectivity testing to only permit safe targets
by enforcing allowed schemes (require https), resolve and verify host IPs do not
fall into RFC1918, localhost, link‑local or other reserved ranges (check both A
and AAAA), enforce an explicit allowlist of known domains or configured
instances, reject requests that resolve to private IPs or hostnames, limit
redirects and request timeouts, and ensure unit/integration tests assert these
validations rather than contacting arbitrary endpoints.
| - [ ] 5. Create backend API endpoints for frontend integration | ||
| - [ ] 5.1 Implement property search and retrieval endpoints | ||
| - Create GET /api/wikibase/instances/:instanceId/properties/search endpoint | ||
| - Create GET /api/wikibase/instances/:instanceId/properties/:propertyId endpoint | ||
| - Add request validation and error handling middleware | ||
| - Write API integration tests for property endpoints | ||
| - _Requirements: 1.2, 1.3_ | ||
|
|
||
| - [ ] 5.2 Implement constraint and validation endpoints | ||
| - Create GET /api/wikibase/instances/:instanceId/properties/:propertyId/constraints endpoint | ||
| - Create POST /api/wikibase/instances/:instanceId/validate endpoint for value validation | ||
| - Add response caching headers and cache control | ||
| - Write API integration tests for constraint endpoints | ||
| - _Requirements: 2.1, 2.2, 5.1_ | ||
|
|
||
| - [ ] 5.3 Implement instance management endpoints | ||
| - Create GET /api/wikibase/instances endpoint for listing available instances | ||
| - Create POST /api/wikibase/instances endpoint for adding custom instances | ||
| - Create GET /api/wikibase/instances/:instanceId/health endpoint for connectivity testing | ||
| - Write API integration tests for instance management | ||
| - _Requirements: 4.1, 4.2, 4.5_ | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Secure backend endpoints (rate limiting, CSRF, input validation, audit)
Make security tasks explicit to avoid regressions when exposing proxy endpoints.
- [ ] 5.1 Implement property search and retrieval endpoints
- Create GET /api/wikibase/instances/:instanceId/properties/search endpoint
- Create GET /api/wikibase/instances/:instanceId/properties/:propertyId endpoint
- - Add request validation and error handling middleware
+ - Add request validation (schemas), error handling, and per-user/IP rate limiting
+ - Emit audit logs with instanceId and requester identity
- Write API integration tests for property endpoints
- _Requirements: 1.2, 1.3_
@@
- [ ] 5.2 Implement constraint and validation endpoints
- Create GET /api/wikibase/instances/:instanceId/properties/:propertyId/constraints endpoint
- Create POST /api/wikibase/instances/:instanceId/validate endpoint for value validation
- - Add response caching headers and cache control
+ - Add CSRF protection for POST, response caching headers, and cache control
- Write API integration tests for constraint endpoints
- _Requirements: 2.1, 2.2, 5.1_
@@
- [ ] 5.3 Implement instance management endpoints
- Create GET /api/wikibase/instances endpoint for listing available instances
- Create POST /api/wikibase/instances endpoint for adding custom instances
- Create GET /api/wikibase/instances/:instanceId/health endpoint for connectivity testing
- - Write API integration tests for instance management
+ - Add strong input validation, authZ, and SSRF mitigations; write API integration tests
- _Requirements: 4.1, 4.2, 4.5_📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - [ ] 5. Create backend API endpoints for frontend integration | |
| - [ ] 5.1 Implement property search and retrieval endpoints | |
| - Create GET /api/wikibase/instances/:instanceId/properties/search endpoint | |
| - Create GET /api/wikibase/instances/:instanceId/properties/:propertyId endpoint | |
| - Add request validation and error handling middleware | |
| - Write API integration tests for property endpoints | |
| - _Requirements: 1.2, 1.3_ | |
| - [ ] 5.2 Implement constraint and validation endpoints | |
| - Create GET /api/wikibase/instances/:instanceId/properties/:propertyId/constraints endpoint | |
| - Create POST /api/wikibase/instances/:instanceId/validate endpoint for value validation | |
| - Add response caching headers and cache control | |
| - Write API integration tests for constraint endpoints | |
| - _Requirements: 2.1, 2.2, 5.1_ | |
| - [ ] 5.3 Implement instance management endpoints | |
| - Create GET /api/wikibase/instances endpoint for listing available instances | |
| - Create POST /api/wikibase/instances endpoint for adding custom instances | |
| - Create GET /api/wikibase/instances/:instanceId/health endpoint for connectivity testing | |
| - Write API integration tests for instance management | |
| - _Requirements: 4.1, 4.2, 4.5_ | |
| - [ ] 5.1 Implement property search and retrieval endpoints | |
| - Create GET /api/wikibase/instances/:instanceId/properties/search endpoint | |
| - Create GET /api/wikibase/instances/:instanceId/properties/:propertyId endpoint | |
| - Add request validation (schemas), error handling, and per-user/IP rate limiting | |
| - Emit audit logs with instanceId and requester identity | |
| - Write API integration tests for property endpoints | |
| - _Requirements: 1.2, 1.3_ | |
| - [ ] 5.2 Implement constraint and validation endpoints | |
| - Create GET /api/wikibase/instances/:instanceId/properties/:propertyId/constraints endpoint | |
| - Create POST /api/wikibase/instances/:instanceId/validate endpoint for value validation | |
| - Add CSRF protection for POST, response caching headers, and cache control | |
| - Write API integration tests for constraint endpoints | |
| - _Requirements: 2.1, 2.2, 5.1_ | |
| - [ ] 5.3 Implement instance management endpoints | |
| - Create GET /api/wikibase/instances endpoint for listing available instances | |
| - Create POST /api/wikibase/instances endpoint for adding custom instances | |
| - Create GET /api/wikibase/instances/:instanceId/health endpoint for connectivity testing | |
| - Add strong input validation, authZ, and SSRF mitigations; write API integration tests | |
| - _Requirements: 4.1, 4.2, 4.5_ |
🤖 Prompt for AI Agents
.kiro/specs/wikibase-rest-api-integration/tasks.md around lines 60 to 81: the
task list for backend endpoints is missing explicit security requirements;
update the checklist to add concrete security tasks — add rate limiting
middleware (per-IP and per-user quotas) for all proxy endpoints, require and
validate authentication/authorization for each route, enforce strict input
validation schemas and sanitization for all request parameters and bodies,
protect state-changing endpoints with CSRF mitigation (CSRF tokens or SameSite
cookie checks), enable detailed audit logging (user id, request path, params,
timestamp, remote IP) and error monitoring, include tests and integration checks
for security controls (rate limit behavior, validation rejection, CSRF
protection, audit entries), and note where to add cache-control headers safely
for cached responses.
| - [ ] 8. Create instance management interface | ||
| - [ ] 8.1 Build InstanceManager component | ||
| - Create component for displaying and selecting Wikibase instances | ||
| - Add UI for switching between pre-configured and custom instances | ||
| - Implement instance health status indicators | ||
| - Write component tests for instance selection and status display | ||
| - _Requirements: 4.1, 4.3_ | ||
|
|
||
| - [ ] 8.2 Add custom instance configuration UI | ||
| - Create form for adding custom Wikibase instance configurations | ||
| - Add validation for instance URLs and connectivity testing | ||
| - Implement save/edit/delete operations for custom instances | ||
| - Write component tests for instance configuration management | ||
| - _Requirements: 4.1, 4.2, 4.4, 4.5_ | ||
|
|
There was a problem hiding this comment.
Do not collect/store tokens client-side in instance UI
Ensure custom instance config UI never exposes or persists auth secrets in the browser; route secrets via backend only.
- [ ] 8.2 Add custom instance configuration UI
- Create form for adding custom Wikibase instance configurations
- - Add validation for instance URLs and connectivity testing
+ - Add validation for instance URLs and connectivity testing (no private networks / SSRF protections)
- Implement save/edit/delete operations for custom instances
+ - Ensure secrets are entered via secure backend flow; never stored in localStorage or sent back to the client in responses📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - [ ] 8. Create instance management interface | |
| - [ ] 8.1 Build InstanceManager component | |
| - Create component for displaying and selecting Wikibase instances | |
| - Add UI for switching between pre-configured and custom instances | |
| - Implement instance health status indicators | |
| - Write component tests for instance selection and status display | |
| - _Requirements: 4.1, 4.3_ | |
| - [ ] 8.2 Add custom instance configuration UI | |
| - Create form for adding custom Wikibase instance configurations | |
| - Add validation for instance URLs and connectivity testing | |
| - Implement save/edit/delete operations for custom instances | |
| - Write component tests for instance configuration management | |
| - _Requirements: 4.1, 4.2, 4.4, 4.5_ | |
| - [ ] 8.2 Add custom instance configuration UI | |
| - Create form for adding custom Wikibase instance configurations | |
| - Add validation for instance URLs and connectivity testing (no private networks / SSRF protections) | |
| - Implement save/edit/delete operations for custom instances | |
| - Ensure secrets are entered via secure backend flow; never stored in localStorage or sent back to the client in responses | |
| - Write component tests for instance configuration management | |
| - _Requirements: 4.1, 4.2, 4.4, 4.5_ |
1 participant
No description provided.