آموزش Bolt.new؛ ساخت پورتال مشتری با Database، Login و انتشار امن
با Bolt.new یک پورتال مشتری Full-Stack بسازید؛ از Prompt و مدل داده تا Bolt Database، ورود کاربران، Secret، GitHub، تست دسترسی و انتشار امن روی Bolt Hosting.
Bolt.new یک محیط ساخت اپ با هوش مصنوعی است که در مرورگر کد تولید و اجرا میکند. میتوانید از یک توضیح طبیعی شروع کنید و رابط، Database، Authentication، Server Function و Hosting را در همان پروژه شکل دهید. سرعت شروع بالاست، اما پورتال مشتری فقط وقتی قابل اعتماد است که هر کاربر واقعاً به داده خودش محدود شود.
در این آموزش یک پورتال فارسی برای آژانس طراحی میسازیم. مشتری پروژهها، فایلها و پیامهای خودش را میبیند؛ کارشناس فقط مشتریان تخصیصیافته را مدیریت میکند؛ مدیر به گزارش کل دسترسی دارد. مسیر را از Scope و Prompt تا GitHub، تست امنیت و Publish جلو میبریم.
Bolt.new چیست؟
Bolt یک AI App Builder از خانواده StackBlitz است. Bolt Cloud برای پروژههای جدید Database، Authentication، Server Function، Hosting و Domain را یکپارچه میکند. در صورت نیاز میتوانید Supabase را هم متصل کنید و کد پروژه را برای Version Control به GitHub ببرید.
| قابلیت | کاربرد | کنترل ضروری |
|---|---|---|
| AI Builder | تولید و اصلاح کد با Prompt | درخواست کوچک و Review |
| Bolt Database | ذخیره داده اپ | Schema، Policy و Backup |
| Authentication | Email، Google و Session | Redirect و Reauthentication |
| Secrets | کلید API برای Server Function | عدم نمایش در Browser |
| GitHub | تاریخچه، Branch و انتقال کد | Repository خصوصی و PR |
| Bolt Hosting | انتشار و دامنه سفارشی | Visibility و Smoke Test |
اگر تازه با توسعه از طریق Prompt آشنا شدهاید، راهنمای وایب کدینگ امن را بخوانید. برای دیدن Workflow متفاوت مبتنی بر Branch و Pull Request نیز آموزش v0 by Vercel مفید است.
محدوده پورتال مشتری را کوچک کنید
نسخه اول چهار Entity دارد: User، Client، Project و Message. قابلیتهای پرداخت، چت زنده، امضای قرارداد و AI Agent را به نسخه بعد منتقل کنید. MVP باید فقط Login، مشاهده پروژه، ارسال پیام و دانلود فایل مجاز را پوشش دهد.
- مشتری فقط Project و Messageهای متعلق به ClientId خودش را میبیند.
- کارشناس فقط مشتریان تخصیصیافته را مدیریت میکند.
- مدیر میتواند تخصیص را تغییر دهد و گزارش کل ببیند.
- فایل حذف نمیشود؛ وضعیت Archived و Audit ثبت میشود.
- هر Upload محدودیت نوع، اندازه و مالکیت دارد.
ماتریس دسترسی را پیش از UI بسازید
| عملیات | Client | Staff | Admin |
|---|---|---|---|
| دیدن پروژه خود | بله | در صورت تخصیص | بله |
| دیدن پروژه دیگران | خیر | خیر | بله |
| ارسال پیام | پروژه خود | پروژه تخصیصیافته | بله |
| تغییر ClientId | خیر | خیر | بله |
| مدیریت کاربر | خیر | خیر | بله |
پنهان کردن دکمه در رابط Authorization نیست. Rule یا Server Function باید مالکیت رکورد را دوباره بررسی کند. شناسه Client ارسالی از Browser را معتبر فرض نکنید؛ آن را از Session و رابطه سمت Server استخراج کنید.
مدل داده ساده و قابل مهاجرت
Client فیلدهای Name، OwnerUserId و Status دارد. Project شامل ClientId، Title، Stage و DueDate است. Message نیز ProjectId، AuthorUserId، Body و CreatedAt دارد. برای فایل، Metadata و Object Key نگه دارید و URL عمومی دائمی نسازید.
Prompt اولیه برای Bolt.new
Prompt خوب مخاطب، نقش، Entity، صفحه، محدودیت و معیار پذیرش دارد. ابتدا از Mock Data استفاده کنید تا AI بدون اجازه شما Database و سرویس خارجی نسازد.
یک پورتال مشتری فارسی و RTL بساز. سه نقش Client، Staff و Admin داشته باشد. صفحات Login، Dashboard، فهرست پروژهها، جزئیات پروژه و پیامها را با Mock Data ایجاد کن. Client فقط پروژههای خودش را ببیند؛ Staff فقط پروژههای تخصیصیافته و Admin همه دادهها را ببیند. حالت Loading، Empty، Error و Permission Denied را طراحی کن. فعلاً Database، سرویس خارجی و Secret اضافه نکن. ابتدا Plan، Componentها و مدل داده پیشنهادی را نمایش بده.
پس از ساخت UI، مسیرهای اصلی را کلیک کنید. RTL، موبایل، جدول، فرم و پیام خطا را بررسی کنید. سپس در Prompt جدا از Bolt بخواهید Bolt Database و Authentication را با همان Schema و ماتریس دسترسی اضافه کند.
ساخت مرحلهای با Promptهای قابل آزمون
- UI و Navigation را با داده ساختگی بسازید.
- Schema را تأیید و Database را متصل کنید.
- Email Login را فعال و تأیید ایمیل را روشن کنید.
- نقش و دسترسی سطح رکورد را در Backend اعمال کنید.
- CRUD پروژه و پیام را مرحلهای اضافه کنید.
- Reset Password و Redirect را تنظیم کنید.
- Upload امن و محدود را در مرحله مستقل بسازید.
- GitHub را وصل و تغییرها را در Branch بازبینی کنید.
- پس از Smoke Test روی Hosting منتشر کنید.
بعد از هر مرحله Version History یا Commit سالم داشته باشید. تاریخچه کد جای Backup پایگاه داده را نمیگیرد. مستندات Bolt صریحاً میگوید بازگردانی Version History لزوماً Database متصل به Supabase را Restore نمیکند.
Bolt Database یا Supabase؟
برای پروژه جدید، Bolt Database مسیر سادهتری است و بدون حساب ثالث آماده میشود. اگر تیم Supabase موجود، کنترل پیشرفته یا داده قبلی دارد، اتصال Supabase منطقی است. اتصال Database جدید به پروژهای که از قبل Bolt Database دارد میتواند جایگزینی اتصال و خطر از دست رفتن داده ایجاد کند؛ قبل از هر تغییر Export و Backup بگیرید.
| معیار | Bolt Database | Supabase |
|---|---|---|
| شروع | یکپارچه و سریع | نیازمند اتصال حساب |
| کنترل بیرون Bolt | مدیریت در Bolt | Dashboard مستقل |
| پروژه موجود | مناسب شروع تازه | مناسب زیرساخت قبلی |
| Restore | سیاست Backup را بررسی کنید | Version History کد Database را Restore نمیکند |
| ریسک تغییر اتصال | کم در شروع | جایگزینی بدون Backup خطرناک است |
Authentication و Reset Password
در تنظیمات Authentication میتوانید Signup ایمیلی، تأیید ایمیل، جلوگیری از Password ضعیف، Reauthentication برای تغییر Password و Google Login را مدیریت کنید. برای Production، Site URL و URI Allow List باید دامنه واقعی اپ را پوشش دهند.
لینک Reset معمولاً کاربر را به Redirect مجاز بازمیگرداند. اگر Site URL هنوز localhost:3000 باشد، جریان در سایت زنده خراب میشود. دامنه Production، Previewهای موردنیاز و مسیر Reset را صریح ثبت کنید؛ Wildcard بیش از حد باز نگذارید.
- تأیید ایمیل را برای Signup عمومی فعال کنید.
- تغییر Password را به Session تازه وابسته کنید.
- Redirect فقط به دامنههای تحت کنترل برود.
- پیام Login وجود یا عدم وجود حساب را افشا نکند.
- Session منقضی و Logout کامل را آزمایش کنید.
Secret را فقط در Server Function نگه دارید
Secret برای API Key یا Password سرویس بیرونی است و Server Function میتواند آن را بدون ارسال به دستگاه کاربر بخواند. مقدار Secret را داخل Chat، فایل کد، Repository، Console Log یا متغیر عمومی Frontend قرار ندهید.
| بررسی | وضعیت امن | خطر |
|---|---|---|
| محل استفاده | Server Function | Component مرورگر |
| ذخیره | Secrets settings | فایل Commitشده |
| دسترسی تیم | Editor یا Co-owner ضروری | اشتراک گسترده |
| Log | ماسکشده | چاپ Header و Token |
| Rotation | منظم و پس از Incident | کلید قدیمی دائمی |
برای معماری اتصال امن ابزارها و سرویسها، راهنمای MCP Server را ببینید. هر Integration باید Scope حداقلی و امکان Revoke داشته باشد.
GitHub و قابلیت خروج از Bolt
اتصال GitHub تاریخچه کامل و امکان ادامه توسعه بیرون Bolt را فراهم میکند. Repository اولیه Private و روی main ساخته میشود. برای Feature جدید Branch جدا بسازید و پیش از Merge، Diff و Build را Review کنید.
- Repository را در Organization کسبوکار ایجاد کنید.
- Branch Protection و Pull Request اجباری باشد.
- Secret و فایل Environment وارد Git نشود.
- Dependency جدید از نظر مجوز و امنیت بررسی شود.
- مالک GitHub و مالک Bolt یک فرد موقت نباشد.
در پروژه مشترک، دسترسی Collaborator به داده و Integration را جدی بگیرید. Viewer به Environment Variable دسترسی ندارد، اما Editor و Co-owner میتوانند سطح بالاتری داشته باشند. نقش تیم را با اصل کمترین دسترسی تنظیم و دورهای بازبینی کنید.
تست امنیت پیش از انتشار
سه حساب آزمایشی Client، Staff و Admin بسازید. فقط Happy Path را اجرا نکنید؛ URL مستقیم، Request دستکاریشده، Session منقضی و Upload نامعتبر را هم آزمایش کنید.
- Client A تلاش کند Project متعلق به Client B را باز کند.
- Staff شناسه Assignee را در Request تغییر دهد.
- کاربر مهمان URL فایل را مستقیم درخواست کند.
- Reset Password از دامنه غیرمجاز امتحان شود.
- فایل بزرگ یا پسوند جعلی Upload شود.
- Database قطع و پیام خطای عمومی بررسی شود.
- Secret در Source و Network Response جستوجو شود.
از اطلاعات واقعی مشتری برای Test استفاده نکنید. داده مصنوعی با همان ساختار بسازید و قبل از Publish پاکسازی کنید.
Publish روی Bolt Hosting
پروژههای جدید بهطور پیشفرض از Bolt Hosting استفاده میکنند و امکان Domain سفارشی دارند. پیش از Publish، Build، Database، Authentication و Secretهای محیط Production را بررسی کنید. URL ساختهشده را در پنجره ناشناس باز کنید.
- Environment تولید را از Preview جدا کنید.
- Migration و Backup Database را تأیید کنید.
- Site URL و Redirectهای Auth را به دامنه نهایی تغییر دهید.
- Smoke Test ورود، پروژه و پیام را اجرا کنید.
- SSL، Mobile و خطاهای Console را بررسی کنید.
- Log، مصرف Database و هزینه را پایش کنید.
- نسخه سالم برای Rollback نگه دارید.
اشتباههای رایج
- ساخت همه قابلیتها در یک Prompt: Review و یافتن علت خطا دشوار میشود.
- اعتماد به مخفی شدن Button: Request مستقیم میتواند مجوز ناقص را دور بزند.
- باقی ماندن localhost در Site URL: Login و Reset روی دامنه زنده خراب میشود.
- قرار دادن Secret در Frontend: مقدار در دستگاه کاربر دیده میشود.
- اتکا به Version History برای Database: تاریخچه کد Backup داده نیست.
- انتشار با داده واقعی آزمایشی: Preview به نشت اطلاعات تبدیل میشود.
جمعبندی
Bolt.new میتواند مسیر Prompt تا اپ Full-Stack را کوتاه کند، بهخصوص وقتی Database، Login و Hosting را در یک محیط میخواهید. نتیجه قابل اعتماد از Prompt مرحلهای، Schema کوچک و تست مجوز بهدست میآید.
برای پورتال مشتری، امنیت مهمتر از ظاهر Dashboard است. مالکیت رکورد را در Backend بررسی کنید، Redirectهای Auth را محدود نگه دارید، Secret را فقط در Server Function بخوانید و کد را در GitHub Review کنید.
امروز نسخه UI پورتال را فقط با Mock Data و سه نقش بسازید؛ پیش از اتصال Database، ماتریس دسترسی را تأیید و سناریوی دسترسی Client A به پروژه Client B را به تستها اضافه کنید.