feat: Add user query endpoints for existence check and passkey listing#3
feat: Add user query endpoints for existence check and passkey listing#3eminogrande wants to merge 1 commit into
Conversation
…skeys
## Summary
- Added GET /api/users/:username/exists endpoint to check if a username is registered
- Added GET /api/users/:username/passkeys endpoint to list all passkeys for a user
- Created comprehensive API documentation in docs/API.md
## Changes
### New Endpoints
#### Check User Existence
- **Endpoint**: GET /api/users/:username/exists
- **Purpose**: Verify if a username is already registered in the system
- **Response**: { "exists": true/false }
- **Use Case**: Pre-registration validation in client applications
#### List User Passkeys
- **Endpoint**: GET /api/users/:username/passkeys
- **Purpose**: Retrieve all registered passkeys for a specific user
- **Response**: Array of passkey objects with credentialId, deviceName, lastUsed, and createdAt
- **Features**:
- Automatic device type detection based on transport methods
- Sorted by most recently used
- Returns 404 if user doesn't exist
### Device Name Logic
The endpoint intelligently determines device names based on:
- Transport type 'internal' → "Platform Authenticator" (Face ID, Touch ID, Windows Hello)
- Transport type 'usb' → "Security Key" (YubiKey, etc.)
- Transport types 'ble' or 'nfc' → "Mobile Device"
- Fallback to stored device_name or "Unknown Device"
### Documentation
- Created comprehensive API documentation in docs/API.md
- Updated README.md with references to new endpoints
- Added detailed request/response examples
- Included error handling scenarios
## Technical Details
- Endpoints positioned correctly in the Express routing order (before :identifier routes)
- Proper async/await error handling
- Consistent error response format
- URL-encoded username support (e.g., @ becomes %40)
## Testing
Tested on production server (https://passkey.nuri.com):
- ✅ User existence check working
- ✅ Passkey listing working with proper device name detection
- ✅ Error cases (non-existent users) handled correctly
## Deployment Notes
- Changes are live on production server at passkey.nuri.com
- No database schema changes required
- Backward compatible with existing functionality
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
WalkthroughAdds two public API endpoints for user existence and passkey listing in index.js, updates README section heading and endpoint listings, and introduces a comprehensive API reference at docs/API.md with endpoint details, examples, and guidance. Changes
Sequence Diagram(s)sequenceDiagram
actor Client
participant Server as API Server
participant Store as User Store/DB
rect rgb(235, 245, 255)
note over Client,Server: Check username existence
Client->>Server: GET /api/users/:username/exists
Server->>Server: Validate username
Server->>Store: Find user by username
Store-->>Server: User record | null
Server-->>Client: 200 { exists: true|false } or 400/500
end
rect rgb(245, 235, 255)
note over Client,Server: List user passkeys
Client->>Server: GET /api/users/:username/passkeys
Server->>Server: Validate username
Server->>Store: Get user and authenticators
Store-->>Server: User + authenticators | null
Server->>Server: Map transports→deviceName, format fields, sort by lastUsed
Server-->>Client: 200 [passkeys[]] or 404/400/500
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~15–20 minutes Poem
✨ 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: 0
🧹 Nitpick comments (1)
index.js (1)
791-817: Consider extracting device name logic into a utility function.The device name determination logic is well-implemented but could be made more maintainable by extracting it into a separate utility function, especially if this logic might be reused elsewhere.
+// Utility function to determine device name from authenticator data +function getDeviceName(auth) { + // If we have device info stored, use that + if (auth.device_name) { + return auth.device_name; + } + + // Try to determine device type from transports + if (auth.transports) { + if (auth.transports.includes('internal')) { + return 'Platform Authenticator'; + } else if (auth.transports.includes('usb')) { + return 'Security Key'; + } else if (auth.transports.includes('ble') || auth.transports.includes('nfc')) { + return 'Mobile Device'; + } + } + + return 'Unknown Device'; +} // Format passkeys for response const passkeys = authenticators.map(auth => { - // Extract device name from transports or user agent if available - let deviceName = 'Unknown Device'; - - // Try to determine device type from transports - if (auth.transports) { - if (auth.transports.includes('internal')) { - deviceName = 'Platform Authenticator'; - } else if (auth.transports.includes('usb')) { - deviceName = 'Security Key'; - } else if (auth.transports.includes('ble') || auth.transports.includes('nfc')) { - deviceName = 'Mobile Device'; - } - } - - // If we have device info stored, use that - if (auth.device_name) { - deviceName = auth.device_name; - } - return { credentialId: Buffer.from(auth.credentialID).toString('base64url'), - deviceName: deviceName, + deviceName: getDeviceName(auth), lastUsed: auth.last_used || auth.updated_at || auth.created_at, createdAt: auth.created_at };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
README.md(1 hunks)docs/API.md(1 hunks)index.js(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (CLAUDE.md)
Dashboard should use
window.location.originfor API_BASE instead of hardcodedhttps://localhost
Files:
index.js
🧬 Code Graph Analysis (1)
index.js (1)
db.js (1)
getAuthenticatorsByUserId(126-139)
🔇 Additional comments (8)
README.md (2)
228-231: LGTM - Clear documentation for new endpoints.The section correctly documents the two new public API endpoints with appropriate formatting and clear naming. The section rename from "Dashboard & Management" to "User Query Endpoints" properly categorizes these user-facing endpoints.
238-238: LGTM - Helpful cross-reference to detailed API documentation.The cross-reference line provides users with a clear path to find complete API documentation with examples and detailed specifications.
index.js (2)
750-767: LGTM - Well-implemented username existence check.The endpoint correctly validates the username parameter, uses appropriate error handling, and returns a clear boolean response. The implementation follows the established patterns in the codebase.
769-833: LGTM - Comprehensive passkey listing implementation.The endpoint implementation is well-structured with:
- Proper input validation and error handling
- Clear device name determination logic based on transport types
- Appropriate data formatting (base64url for credential IDs)
- Sorting by most recent usage as specified
- Consistent logging and error responses
The device name mapping logic correctly follows the specification:
internal→ "Platform Authenticator"usb→ "Security Key"ble/nfc→ "Mobile Device"- Fallback to stored
device_nameor "Unknown Device"docs/API.md (4)
1-8: LGTM - Well-structured API documentation.The documentation provides a clear table of contents with logical grouping of endpoints into Authentication, User Management, Data Storage, and Administrative categories.
108-130: LGTM - Clear documentation for user existence endpoint.The endpoint documentation includes proper HTTP method, path parameters, response format, and a practical curl example with URL encoding.
133-186: LGTM - Comprehensive passkeys listing documentation.The documentation thoroughly covers:
- Request/response formats
- Error handling scenarios
- Device name determination logic
- Practical examples with URL encoding
- Clear explanation of the sorting behavior
The device name logic section is particularly helpful for understanding how device types are determined.
362-396: LGTM - Excellent documentation of error handling and security considerations.The documentation provides comprehensive coverage of:
- Consistent error response format
- HTTP status codes
- Rate limiting recommendations
- CORS configuration notes
- Security best practices
This is essential information for production deployments.
1 participant
Summary
This PR adds two new API endpoints to enhance user management capabilities:
New Endpoints
1. Check User Existence
GET /api/users/:username/exists{ "exists": true/false }2. List User Passkeys
GET /api/users/:username/passkeysChanges Made
Code Changes
index.jsDocumentation
docs/API.mdTesting
Production Testing (https://passkey.nuri.com)
Device Name Detection Logic
The passkeys endpoint intelligently determines device types:
internaltransport → "Platform Authenticator" (Face ID, Touch ID, Windows Hello)usbtransport → "Security Key" (YubiKey, etc.)ble/nfctransport → "Mobile Device"Use Cases
Technical Notes
:identifierroutes)Deployment
🤖 Generated with Claude Code
Summary by CodeRabbit