guideai-app 0.4.1 → 0.4.2-1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/API_DATA_CONTRACTS.md +516 -0
- package/API_SESSIONID_TESTING.md +215 -0
- package/PII_HASHING_EPIC.md +886 -0
- package/PII_HASHING_STORIES_SUMMARY.md +275 -0
- package/SESSION_ID_VERIFICATION.md +122 -0
- package/VISIT_COUNT_TESTING.md +453 -0
- package/dist/GuideAI.js +1 -1
- package/dist/GuideAI.js.LICENSE.txt +20 -0
- package/dist/GuideAI.js.map +1 -1
- package/dist/components/TranscriptBox.d.ts +4 -0
- package/dist/index.d.ts +3 -0
- package/dist/metric/index.d.ts +0 -2
- package/dist/metric/metadata-tracker.d.ts +1 -2
- package/dist/styles/GuideAI.styles.d.ts +1 -1
- package/dist/types/GuideAI.types.d.ts +3 -1
- package/dist/types/metadata.types.d.ts +2 -0
- package/dist/utils/api.d.ts +5 -0
- package/dist/utils/elementInteractions.d.ts +92 -0
- package/dist/utils/gemini.d.ts +3 -0
- package/dist/utils/goToAElmLink.d.ts +1 -0
- package/dist/utils/highlightThenClick.d.ts +1 -0
- package/dist/utils/hoverThenClick.d.ts +1 -0
- package/dist/utils/logger.d.ts +1 -5
- package/dist/utils/session.d.ts +23 -0
- package/dist/utils/ui.d.ts +1 -1
- package/dist/visualContext/VisualContextScheduler.d.ts +43 -0
- package/dist/visualContext/VisualContextStore.d.ts +11 -0
- package/dist/visualContext/debug-overlay.d.ts +10 -0
- package/dist/visualContext/defaultProvider.d.ts +15 -0
- package/dist/visualContext/index.d.ts +5 -0
- package/dist/visualContext/types.d.ts +45 -0
- package/index.d.ts +5 -1
- package/jest.config.js +26 -0
- package/jest.setup.js +21 -0
- package/metadata-tracking-example.md +11 -11
- package/package.json +14 -3
- package/dist/metric/event-listner.d.ts +0 -141
- package/dist/utils/highlightAndClick.d.ts +0 -3
- package/dist/utils/hoverAndClick.d.ts +0 -4
|
@@ -0,0 +1,275 @@
|
|
|
1
|
+
# PII Hashing - Story Summary
|
|
2
|
+
|
|
3
|
+
**Epic Goal:** Implement client-side PII hashing to prevent sensitive data from appearing in logs, monitoring tools, and backend systems.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Frontend Stories (Guide AI Package)
|
|
8
|
+
|
|
9
|
+
### ✅ FE-1: Create PII Hashing Utility
|
|
10
|
+
**Points:** 3 | **Priority:** P0 | **Dependencies:** None
|
|
11
|
+
|
|
12
|
+
Create `src/utils/pii.ts` with:
|
|
13
|
+
- `hashEmail()` - Hash email using SHA-256
|
|
14
|
+
- `hashPII()` - Generic PII hashing function
|
|
15
|
+
- `isHashed()` - Check if value is already hashed
|
|
16
|
+
- TypeScript types and JSDoc
|
|
17
|
+
- Works with Web Crypto API
|
|
18
|
+
|
|
19
|
+
**Deliverables:**
|
|
20
|
+
- New file: `src/utils/pii.ts`
|
|
21
|
+
- TypeScript types for hashed data
|
|
22
|
+
- Documentation
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
### ✅ FE-2: Update UserMetadataTracker to Hash Emails
|
|
27
|
+
**Points:** 5 | **Priority:** P0 | **Dependencies:** FE-1
|
|
28
|
+
|
|
29
|
+
Update `src/metric/metadata-tracker.tsx`:
|
|
30
|
+
- Hash emails in `updateUserInfo()`
|
|
31
|
+
- Hash emails in `trackLogin()`
|
|
32
|
+
- Hash emails in all `trackVisit*()` methods
|
|
33
|
+
- Hash emails in `trackCustomEvent()`
|
|
34
|
+
- Store hashed emails in localStorage
|
|
35
|
+
- Add migration logic for existing data
|
|
36
|
+
- Graceful error handling
|
|
37
|
+
|
|
38
|
+
**Deliverables:**
|
|
39
|
+
- Modified: `src/metric/metadata-tracker.tsx`
|
|
40
|
+
- All emails hashed before storage/transmission
|
|
41
|
+
- Backward compatible
|
|
42
|
+
|
|
43
|
+
---
|
|
44
|
+
|
|
45
|
+
### ✅ FE-3: Update API Layer for Hashed Identifiers
|
|
46
|
+
**Points:** 3 | **Priority:** P0 | **Dependencies:** FE-1, FE-2
|
|
47
|
+
|
|
48
|
+
Update API types and validation:
|
|
49
|
+
- Add `emailHash` field to `UserMetadata` type
|
|
50
|
+
- Deprecate `email` field (keep for backward compatibility)
|
|
51
|
+
- Add validation in `sendMetadataUpdates()` (dev mode)
|
|
52
|
+
- Ensure no plain-text emails in API calls
|
|
53
|
+
- Update JSDoc comments
|
|
54
|
+
|
|
55
|
+
**Deliverables:**
|
|
56
|
+
- Modified: `src/types/metadata.types.ts`
|
|
57
|
+
- Modified: `src/utils/api.ts`
|
|
58
|
+
- API request validation
|
|
59
|
+
|
|
60
|
+
---
|
|
61
|
+
|
|
62
|
+
### ✅ FE-4: Add Privacy Configuration Options
|
|
63
|
+
**Points:** 2 | **Priority:** P1 | **Dependencies:** FE-1, FE-2
|
|
64
|
+
|
|
65
|
+
Add config options to `MetadataConfig`:
|
|
66
|
+
- `enablePIIHashing: boolean` (default: true)
|
|
67
|
+
- `piiFields: string[]` (default: ['email'])
|
|
68
|
+
- `allowPlainTextFallback: boolean` (default: false)
|
|
69
|
+
|
|
70
|
+
**Deliverables:**
|
|
71
|
+
- Modified: `src/types/metadata.types.ts`
|
|
72
|
+
- Configuration documentation
|
|
73
|
+
- Usage examples
|
|
74
|
+
|
|
75
|
+
---
|
|
76
|
+
|
|
77
|
+
### ✅ FE-5: Add Unit & Integration Tests
|
|
78
|
+
**Points:** 5 | **Priority:** P0 | **Dependencies:** FE-1, FE-2, FE-3
|
|
79
|
+
|
|
80
|
+
Create comprehensive test coverage:
|
|
81
|
+
- Unit tests for `pii.ts` utilities
|
|
82
|
+
- Unit tests for metadata tracker hashing
|
|
83
|
+
- Integration tests for end-to-end flow
|
|
84
|
+
- Test error handling and edge cases
|
|
85
|
+
- Verify no plain-text in API calls
|
|
86
|
+
|
|
87
|
+
**Deliverables:**
|
|
88
|
+
- New file: `src/utils/pii.test.ts`
|
|
89
|
+
- New file: `src/metric/metadata-tracker.pii.test.ts`
|
|
90
|
+
- 90%+ code coverage
|
|
91
|
+
- All tests passing in CI
|
|
92
|
+
|
|
93
|
+
---
|
|
94
|
+
|
|
95
|
+
## Backend Stories (High Level - Other Repo)
|
|
96
|
+
|
|
97
|
+
### 🔧 BE-1: Update API Endpoints for Hashed Email Handling
|
|
98
|
+
**Points:** 8 | **Priority:** P0
|
|
99
|
+
|
|
100
|
+
**What:**
|
|
101
|
+
- Update `/initialize-session` endpoint to accept `emailHash`
|
|
102
|
+
- Update `/metadata-updates` endpoint to process `emailHash`
|
|
103
|
+
- Add hash format validation (64 hex chars)
|
|
104
|
+
- Ensure backward compatibility during migration
|
|
105
|
+
- Update API documentation
|
|
106
|
+
|
|
107
|
+
**Technical Notes:**
|
|
108
|
+
- Accept both `email` and `emailHash` during transition
|
|
109
|
+
- Validate hash format: `/^[a-f0-9]{64}$/i`
|
|
110
|
+
- No plain-text emails in logs
|
|
111
|
+
|
|
112
|
+
---
|
|
113
|
+
|
|
114
|
+
### 🔧 BE-2: Create Email Hash Mapping System
|
|
115
|
+
**Points:** 13 | **Priority:** P0
|
|
116
|
+
|
|
117
|
+
**What:**
|
|
118
|
+
- Create `email_mappings` table
|
|
119
|
+
- Store: `emailHash → encryptedEmail`
|
|
120
|
+
- Implement encryption at rest (AES-256-GCM)
|
|
121
|
+
- Use KMS for key management
|
|
122
|
+
- Add Redis cache for frequently accessed mappings
|
|
123
|
+
- Implement audit logging
|
|
124
|
+
- Create internal API for email lookup
|
|
125
|
+
|
|
126
|
+
**Database Schema:**
|
|
127
|
+
```sql
|
|
128
|
+
email_mappings (
|
|
129
|
+
email_hash: VARCHAR(64) PRIMARY KEY,
|
|
130
|
+
encrypted_email: BYTEA,
|
|
131
|
+
encryption_key_id: VARCHAR(50),
|
|
132
|
+
organization_key: VARCHAR(100),
|
|
133
|
+
first_seen: TIMESTAMP,
|
|
134
|
+
last_seen: TIMESTAMP
|
|
135
|
+
)
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
### 🔧 BE-3: Update Database Schema
|
|
141
|
+
**Points:** 5 | **Priority:** P0
|
|
142
|
+
|
|
143
|
+
**What:**
|
|
144
|
+
- Add `email_hash` column to relevant tables
|
|
145
|
+
- Migrate existing plain-text emails to hashes
|
|
146
|
+
- Create indexes on `email_hash`
|
|
147
|
+
- Update all queries to use `email_hash`
|
|
148
|
+
- Keep `email` column temporarily for backward compatibility
|
|
149
|
+
|
|
150
|
+
**Migration Strategy:**
|
|
151
|
+
1. Add new column
|
|
152
|
+
2. Backfill hashes (incremental)
|
|
153
|
+
3. Create indexes
|
|
154
|
+
4. Update application code
|
|
155
|
+
5. (Future) Drop old email column
|
|
156
|
+
|
|
157
|
+
---
|
|
158
|
+
|
|
159
|
+
### 🔧 BE-4: Add Email Retrieval & Notification Logic
|
|
160
|
+
**Points:** 8 | **Priority:** P1
|
|
161
|
+
|
|
162
|
+
**What:**
|
|
163
|
+
- Create service for secure email retrieval
|
|
164
|
+
- Implement notification service using email lookup
|
|
165
|
+
- Add authentication/authorization
|
|
166
|
+
- Implement audit logging for email access
|
|
167
|
+
- Add rate limiting
|
|
168
|
+
- Monitoring/alerts for suspicious access
|
|
169
|
+
|
|
170
|
+
**Access Control:**
|
|
171
|
+
- Only notification service can retrieve emails
|
|
172
|
+
- Service-to-service authentication
|
|
173
|
+
- Rate limit: 100 lookups/minute per service
|
|
174
|
+
- IP whitelisting
|
|
175
|
+
|
|
176
|
+
---
|
|
177
|
+
|
|
178
|
+
## Story Point Summary
|
|
179
|
+
|
|
180
|
+
| Team | Total Points | Stories |
|
|
181
|
+
|------|--------------|---------|
|
|
182
|
+
| **Frontend** | **18 points** | 5 stories |
|
|
183
|
+
| **Backend** | **34 points** | 4 stories |
|
|
184
|
+
| **TOTAL** | **52 points** | 9 stories |
|
|
185
|
+
|
|
186
|
+
---
|
|
187
|
+
|
|
188
|
+
## Sprint Allocation (Example)
|
|
189
|
+
|
|
190
|
+
### Sprint 1: Core Implementation
|
|
191
|
+
- FE-1: Create PII Hashing Utility (3 pts)
|
|
192
|
+
- FE-2: Update UserMetadataTracker (5 pts)
|
|
193
|
+
- BE-1: Update API Endpoints (8 pts)
|
|
194
|
+
- **Total: 16 points**
|
|
195
|
+
|
|
196
|
+
### Sprint 2: Integration & Mapping
|
|
197
|
+
- FE-3: Update API Layer (3 pts)
|
|
198
|
+
- FE-4: Add Privacy Config (2 pts)
|
|
199
|
+
- BE-2: Email Hash Mapping System (13 pts)
|
|
200
|
+
- **Total: 18 points**
|
|
201
|
+
|
|
202
|
+
### Sprint 3: Testing & Deployment
|
|
203
|
+
- FE-5: Tests (5 pts)
|
|
204
|
+
- BE-3: Database Schema (5 pts)
|
|
205
|
+
- BE-4: Email Retrieval Logic (8 pts)
|
|
206
|
+
- **Total: 18 points**
|
|
207
|
+
|
|
208
|
+
---
|
|
209
|
+
|
|
210
|
+
## Critical Path
|
|
211
|
+
|
|
212
|
+
```
|
|
213
|
+
FE-1 (PII Utils)
|
|
214
|
+
↓
|
|
215
|
+
FE-2 (Metadata Tracker) + BE-1 (API Endpoints)
|
|
216
|
+
↓
|
|
217
|
+
FE-3 (API Layer) + BE-2 (Email Mapping)
|
|
218
|
+
↓
|
|
219
|
+
FE-5 (Tests) + BE-3 (DB Schema) + BE-4 (Email Retrieval)
|
|
220
|
+
↓
|
|
221
|
+
Integration Testing
|
|
222
|
+
↓
|
|
223
|
+
Production Deployment
|
|
224
|
+
```
|
|
225
|
+
|
|
226
|
+
---
|
|
227
|
+
|
|
228
|
+
## Quick Checklist
|
|
229
|
+
|
|
230
|
+
**Before Starting:**
|
|
231
|
+
- [ ] Product approval for privacy changes
|
|
232
|
+
- [ ] Security review of approach
|
|
233
|
+
- [ ] Backend team capacity confirmed
|
|
234
|
+
- [ ] Database migration plan reviewed
|
|
235
|
+
|
|
236
|
+
**During Development:**
|
|
237
|
+
- [ ] Daily syncs between FE/BE teams
|
|
238
|
+
- [ ] Test in staging after each story
|
|
239
|
+
- [ ] Security scanning of new code
|
|
240
|
+
- [ ] Performance testing
|
|
241
|
+
|
|
242
|
+
**Before Production:**
|
|
243
|
+
- [ ] All tests passing
|
|
244
|
+
- [ ] Privacy audit completed
|
|
245
|
+
- [ ] Rollback plan documented
|
|
246
|
+
- [ ] Monitoring configured
|
|
247
|
+
- [ ] Team trained on new system
|
|
248
|
+
|
|
249
|
+
---
|
|
250
|
+
|
|
251
|
+
## Key Decisions Needed
|
|
252
|
+
|
|
253
|
+
1. **Migration Timeline:** How long to support both `email` and `emailHash`?
|
|
254
|
+
2. **Rollout Strategy:** Big bang or gradual rollout?
|
|
255
|
+
3. **Old Data:** Migrate existing emails in DB or only new data?
|
|
256
|
+
4. **Other PII:** Should we hash other fields (userId, customerLicense)?
|
|
257
|
+
5. **Encryption Keys:** Where to store? AWS KMS? Vault?
|
|
258
|
+
|
|
259
|
+
---
|
|
260
|
+
|
|
261
|
+
## Success Criteria
|
|
262
|
+
|
|
263
|
+
✅ No plain-text emails in server logs
|
|
264
|
+
✅ No plain-text emails in API requests
|
|
265
|
+
✅ All notifications still work
|
|
266
|
+
✅ < 50ms latency impact
|
|
267
|
+
✅ 99.9% uptime during migration
|
|
268
|
+
✅ Privacy audit passed
|
|
269
|
+
|
|
270
|
+
---
|
|
271
|
+
|
|
272
|
+
**Created:** [Date]
|
|
273
|
+
**Owner:** [Name]
|
|
274
|
+
**Status:** Ready for Planning
|
|
275
|
+
|
|
@@ -0,0 +1,122 @@
|
|
|
1
|
+
# Session ID Implementation Verification Guide
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
This guide helps you verify that the session ID tracking implementation is working correctly.
|
|
5
|
+
|
|
6
|
+
## What Was Implemented
|
|
7
|
+
|
|
8
|
+
### 1. Session Utility (`src/utils/session.ts`)
|
|
9
|
+
- ✅ `getSessionId()` - Gets or creates session ID
|
|
10
|
+
- ✅ `clearSessionId()` - Clears session ID (for testing)
|
|
11
|
+
- ✅ `peekSessionId()` - Views session ID without creating one
|
|
12
|
+
- ✅ Standard UUID v4 format
|
|
13
|
+
- ✅ Stored in `sessionStorage['guideai_session_id']`
|
|
14
|
+
|
|
15
|
+
### 2. UserMetadataTracker Updates
|
|
16
|
+
- ✅ Session ID initialized in `init()` method
|
|
17
|
+
- ✅ Session ID stored in metadata object
|
|
18
|
+
- ✅ Session ID included in all metadata updates
|
|
19
|
+
|
|
20
|
+
### 3. Exports
|
|
21
|
+
- ✅ Session utility functions exported from main index
|
|
22
|
+
- ✅ Available for external debugging and testing
|
|
23
|
+
|
|
24
|
+
## Manual Verification Steps
|
|
25
|
+
|
|
26
|
+
### Step 1: Check Session Storage
|
|
27
|
+
1. Open your test site in a browser
|
|
28
|
+
2. Open DevTools → Application → Session Storage
|
|
29
|
+
3. Look for `guideai_session_id`
|
|
30
|
+
4. Verify it contains a UUID (e.g., `550e8400-e29b-41d4-a716-446655440000`)
|
|
31
|
+
|
|
32
|
+
### Step 2: Verify Persistence
|
|
33
|
+
1. Navigate between different pages on your site
|
|
34
|
+
2. Check that `guideai_session_id` remains the same
|
|
35
|
+
3. Refresh the page - session ID should persist
|
|
36
|
+
|
|
37
|
+
### Step 3: Verify New Session Creation
|
|
38
|
+
1. Open a new tab to the same site
|
|
39
|
+
2. Check Session Storage - should have a different `guideai_session_id`
|
|
40
|
+
3. Close and reopen a tab - should generate a new `guideai_session_id`
|
|
41
|
+
|
|
42
|
+
### Step 4: Verify Metadata Tracking
|
|
43
|
+
Open the browser console and check logs:
|
|
44
|
+
|
|
45
|
+
```javascript
|
|
46
|
+
// UserMetadataTracker should log:
|
|
47
|
+
// "Session ID initialized" with { sessionId: "..." }
|
|
48
|
+
|
|
49
|
+
// metadata object should include sessionId
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
### Step 6: Programmatic Testing
|
|
53
|
+
You can test session functions directly in the console:
|
|
54
|
+
|
|
55
|
+
```javascript
|
|
56
|
+
// Get current session ID
|
|
57
|
+
const { getSessionId, peekSessionId, clearSessionId } = window.GuideAI || {};
|
|
58
|
+
|
|
59
|
+
// View current session ID (if GuideAI exports are available)
|
|
60
|
+
console.log('Current session:', peekSessionId());
|
|
61
|
+
|
|
62
|
+
// Or directly from sessionStorage
|
|
63
|
+
console.log('Session ID:', sessionStorage.getItem('guideai_session_id'));
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
## Expected Behavior
|
|
67
|
+
|
|
68
|
+
### Session Lifecycle
|
|
69
|
+
- **New Tab**: New session ID generated
|
|
70
|
+
- **Page Navigation**: Session ID persists
|
|
71
|
+
- **Page Refresh**: Session ID persists
|
|
72
|
+
- **Tab Close**: Session ID cleared automatically
|
|
73
|
+
- **Browser Restart**: New session IDs for all tabs
|
|
74
|
+
|
|
75
|
+
### Data Inclusion
|
|
76
|
+
- **UserMetadataTracker**: Metadata should include `sessionId` field
|
|
77
|
+
- **API Calls**: Session ID should be sent to backend with metadata updates
|
|
78
|
+
|
|
79
|
+
## Testing in Your Application
|
|
80
|
+
|
|
81
|
+
Add this code to your test application to verify session tracking:
|
|
82
|
+
|
|
83
|
+
```typescript
|
|
84
|
+
import GuideAI, { getSessionId } from 'guideai-package';
|
|
85
|
+
|
|
86
|
+
// In your component
|
|
87
|
+
useEffect(() => {
|
|
88
|
+
// Log session ID on mount
|
|
89
|
+
console.log('Current GuideAI Session:', getSessionId());
|
|
90
|
+
|
|
91
|
+
// Check sessionStorage directly
|
|
92
|
+
console.log('Session Storage:', sessionStorage.getItem('guideai_session_id'));
|
|
93
|
+
}, []);
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
## Common Issues & Solutions
|
|
97
|
+
|
|
98
|
+
### Issue: Session ID not appearing
|
|
99
|
+
**Solution**: Ensure GuideAI component has mounted and initialized
|
|
100
|
+
|
|
101
|
+
### Issue: Session ID changes on page refresh
|
|
102
|
+
**Solution**: Verify you're using `sessionStorage` not `localStorage`
|
|
103
|
+
|
|
104
|
+
### Issue: Same session ID across tabs
|
|
105
|
+
**Solution**: This is expected behavior - each tab should have its own session ID
|
|
106
|
+
|
|
107
|
+
## Phase 2 Features (Not Yet Implemented)
|
|
108
|
+
|
|
109
|
+
These features are planned for future releases:
|
|
110
|
+
- ❌ `session_start` metadata event
|
|
111
|
+
- ❌ `session_end` metadata event
|
|
112
|
+
- ❌ Session duration tracking
|
|
113
|
+
- ❌ Session-level analytics
|
|
114
|
+
|
|
115
|
+
## Notes
|
|
116
|
+
|
|
117
|
+
- Session ID uses browser's `crypto.randomUUID()` when available
|
|
118
|
+
- Fallback UUID generation for older browsers
|
|
119
|
+
- Global session key (not per-organization)
|
|
120
|
+
- `conversationStartTime` remains for backward compatibility
|
|
121
|
+
- Session utility handles SSR/non-browser environments gracefully
|
|
122
|
+
|