trent_larson/README-first
4
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

refine cursor rules for pagination

Browse Source
This commit is contained in:
Trent Larson
2025-12-24 13:23:30 -07:00
parent d4f714d14d
commit 05d500f2a3
2 changed files with 13 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.cursor/rules/README.mdc
View File

@@ -53,6 +53,8 @@ Secondary Repos:
- endorser-mobile is the previous native app to talk to the Endorser server -- very powerful but harder to use
### Hosting
These repos are hosted by GitHub: endorser-ch, endorser-mobile, lives-of-gifts uport-demo, endorser-docs, time-safari-web
The remaining repos are hosted by gitea.anomalistdesign.com

34
.cursor/rules/endorser-service.mdc
View File

@@ -100,26 +100,13 @@ const result = {
When creating new paginated endpoints:
- [ ] Use `beforeId`/`afterId` query parameters in routes
- [ ] Pass these parameters to database methods as `afterIdInput`/`beforeIdInput`
- [ ] Use JWT ID comparisons (`jwtId > ?`, `jwtId < ?`) in SQL
- [ ] Return `{ data: [], hitLimit: boolean }` response format
- [ ] Document parameters with standard JSDoc format
- [ ] Never use `limit`, `offset`, `page`, or similar parameters
## Error Prevention
**Red Flags** - These patterns should be avoided:
- Any mention of `limit` or `offset` in parameter names
- `LIMIT ? OFFSET ?` in SQL queries
- `parseInt(req.query.limit)` in route handlers
- Response objects with `page`, `totalPages`, `totalCount` fields
**Green Flags** - These patterns should be used:
- `beforeId`/`afterId` parameter naming
- `jwtId > ?` and `jwtId < ?` SQL conditions
- `hitLimit` boolean in responses
- `DEFAULT_LIMIT` constant for consistent limits
- Use `beforeId`/`afterId` query parameters in routes
- Pass these parameters to database methods as `afterIdInput`/`beforeIdInput`
- Use JWT ID comparisons (`jwtId > ?`, `jwtId < ?`) in SQL
- Include `DEFAULT_LIMIT` constant in SQL for consistent limits
- Return `{ data: [], hitLimit: boolean }` response format
- Document parameters with standard JSDoc format
- Never use `limit`, `offset`, `page`, or similar parameters
# Database Migration Documentation
@@ -181,7 +168,7 @@ async function hideDidsAndAddLinksToNetworkInDataKey(requesterDid, input, search
### Critical searchTerms Parameter
**SECURITY REQUIREMENT**: The `searchTerms` parameter MUST contain any user-provided query data that might include DIDs or parts of DIDs.
**SECURITY REQUIREMENT**: The `searchTerms` parameter MUST contain all user-provided query data (since it might include DIDs or parts of DIDs).
#### Why searchTerms is Required
@@ -234,8 +221,9 @@ Always include search terms when:
### Security Checklist
When implementing endpoints that use `hideDidsAndAddLinksToNetwork`:
When implementing endpoints, always consider usage of `hideDidsAndAddLinksToNetwork`:
- [ ] Use it for almost every endpoint, and exceptions should be vetted and documented
- [ ] Identify all user-provided query parameters
- [ ] Include any parameter that could contain DIDs in `searchTerms`
- [ ] Include any text search parameters in `searchTerms`
@@ -255,4 +243,4 @@ When implementing endpoints that use `hideDidsAndAddLinksToNetwork`:
- Including all user query parameters that might contain DIDs
- Using `[]` only for endpoints with no user search input
- Consistent application across all endpoints returning DID data
- Proper testing of search result filtering
- Proper testing of search result filtering