102 lines
3.1 KiB
Markdown
102 lines
3.1 KiB
Markdown
# Mixed Content Fix - HTTPS Image URLs
|
|
|
|
## Problem
|
|
|
|
When the site is served over HTTPS (via ngrok), images from Strapi using HTTP URLs (`http://160.187.167.213/uploads/...`) were blocked by browsers due to Mixed Content security policies. This caused:
|
|
- Missing images
|
|
- Layout shifts (CLS - Cumulative Layout Shift)
|
|
- Poor user experience
|
|
|
|
## Solution
|
|
|
|
Created a utility function `ensureHttpsImageUrl()` that automatically converts HTTP image URLs to HTTPS when the site is served over HTTPS.
|
|
|
|
### Implementation
|
|
|
|
**New Utility Function** (`lib/utils.ts`):
|
|
- Detects if the site is served over HTTPS (checks `window.location.protocol`)
|
|
- Automatically converts HTTP URLs to HTTPS
|
|
- Handles relative URLs, absolute URLs, and protocol-relative URLs
|
|
- Works seamlessly in both development and production
|
|
|
|
### Updated Components
|
|
|
|
All components that load images from Strapi now use the utility function:
|
|
|
|
1. ✅ **navbar.tsx** - Logo images
|
|
2. ✅ **testimonials.tsx** - Avatar images
|
|
3. ✅ **trusted-by.tsx** - Trusted school logos
|
|
4. ✅ **footer.tsx** - Footer logo
|
|
|
|
### How It Works
|
|
|
|
```typescript
|
|
// Before (caused Mixed Content errors):
|
|
const imageUrl = `http://160.187.167.213${url}`
|
|
|
|
// After (automatically uses HTTPS when needed):
|
|
const imageUrl = ensureHttpsImageUrl(url)
|
|
```
|
|
|
|
The function:
|
|
1. Checks if the current page is served over HTTPS
|
|
2. If yes, converts any HTTP URLs to HTTPS
|
|
3. If no, keeps the original protocol
|
|
4. Handles all URL formats (relative, absolute, protocol-relative)
|
|
|
|
## Benefits
|
|
|
|
1. **No More Mixed Content Errors**: Images load correctly when site is served over HTTPS
|
|
2. **No Layout Shifts**: Images load properly, preventing CLS issues
|
|
3. **Automatic Detection**: Works automatically without manual configuration
|
|
4. **Backward Compatible**: Still works with HTTP in development
|
|
5. **Centralized Logic**: All image URL handling in one place
|
|
|
|
## Testing
|
|
|
|
To test the fix:
|
|
|
|
1. **Local Development (HTTP)**:
|
|
```bash
|
|
npm run dev
|
|
# Images should load normally with HTTP URLs
|
|
```
|
|
|
|
2. **Ngrok (HTTPS)**:
|
|
```bash
|
|
ngrok http 3000
|
|
# Access via ngrok HTTPS URL
|
|
# Images should automatically use HTTPS URLs
|
|
```
|
|
|
|
3. **Production (HTTPS)**:
|
|
- Deploy to production with HTTPS
|
|
- Images will automatically use HTTPS
|
|
|
|
## Browser Console
|
|
|
|
Before the fix, you would see:
|
|
```
|
|
Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure image 'http://160.187.167.213/uploads/...'. This content should also be served over HTTPS.
|
|
```
|
|
|
|
After the fix:
|
|
- No Mixed Content warnings
|
|
- All images load correctly
|
|
- No console errors
|
|
|
|
## Notes
|
|
|
|
- The utility function only converts HTTP to HTTPS when the site itself is served over HTTPS
|
|
- In development (HTTP), images will still use HTTP (no conversion needed)
|
|
- The function is safe to use everywhere image URLs are constructed
|
|
- It handles edge cases like protocol-relative URLs (`//example.com`)
|
|
|
|
## Future Improvements
|
|
|
|
If Strapi is ever configured to serve images over HTTPS directly, you can:
|
|
1. Update `NEXT_PUBLIC_STRAPI_BASE_URL` to use HTTPS
|
|
2. The utility function will still work correctly
|
|
3. Or remove the utility function if all URLs are already HTTPS
|
|
|