وبلاگ / راهنمای مسیر یادگیری و فناوری
راهنمای مسیر یادگیری و فناوری

آموزش Bolt.new؛ ساخت پورتال مشتری با Database، Login و انتشار امن

با Bolt.new یک پورتال مشتری Full-Stack بسازید؛ از Prompt و مدل داده تا Bolt Database، ورود کاربران، Secret، GitHub، تست دسترسی و انتشار امن روی Bolt Hosting.

· ۲۱ بازدید

یک محیط ساخت اپ با است که در مرورگر کد تولید و اجرا می‌کند. می‌توانید از یک توضیح طبیعی شروع کنید و رابط، ، ، Server Function و Hosting را در همان پروژه شکل دهید. سرعت شروع بالاست، اما پورتال مشتری فقط وقتی قابل اعتماد است که هر کاربر واقعاً به داده خودش محدود شود.

در این آموزش یک پورتال فارسی برای آژانس طراحی می‌سازیم. مشتری پروژه‌ها، فایل‌ها و پیام‌های خودش را می‌بیند؛ کارشناس فقط مشتریان تخصیص‌یافته را مدیریت می‌کند؛ مدیر به گزارش کل دسترسی دارد. مسیر را از Scope و Prompt تا ، تست امنیت و Publish جلو می‌بریم.

چیست؟

Bolt یک AI App Builder از خانواده StackBlitz است. برای پروژه‌های جدید ، ، Server Function، Hosting و Domain را یکپارچه می‌کند. در صورت نیاز می‌توانید Supabase را هم متصل کنید و کد پروژه را برای Version Control به ببرید.

قابلیتکاربردکنترل ضروری
AI Builderتولید و اصلاح کد با Promptدرخواست کوچک و Review
Bolt ذخیره داده اپSchema، Policy و Backup
Email، Google و SessionRedirect و Reauthentication
Secretsکلید API برای Server Functionعدم نمایش در Browser
تاریخچه، 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 بسازید

عملیاتClientStaffAdmin
دیدن پروژه خودبلهدر صورت تخصیصبله
دیدن پروژه دیگرانخیرخیربله
ارسال پیامپروژه خودپروژه تخصیص‌یافتهبله
تغییر 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 اولیه برای

Prompt خوب مخاطب، نقش، Entity، صفحه، محدودیت و معیار پذیرش دارد. ابتدا از Mock Data استفاده کنید تا AI بدون اجازه شما و سرویس خارجی نسازد.

یک پورتال مشتری فارسی و RTL بساز. سه نقش Client، Staff و Admin داشته باشد. صفحات Login، Dashboard، فهرست پروژه‌ها، جزئیات پروژه و پیام‌ها را با Mock Data ایجاد کن. Client فقط پروژه‌های خودش را ببیند؛ Staff فقط پروژه‌های تخصیص‌یافته و Admin همه داده‌ها را ببیند. حالت Loading، Empty، Error و Permission Denied را طراحی کن. فعلاً ، سرویس خارجی و Secret اضافه نکن. ابتدا Plan، Componentها و مدل داده پیشنهادی را نمایش بده.

پس از ساخت UI، مسیرهای اصلی را کلیک کنید. RTL، موبایل، جدول، فرم و پیام خطا را بررسی کنید. سپس در Prompt جدا از Bolt بخواهید Bolt و را با همان Schema و ماتریس دسترسی اضافه کند.

ساخت مرحله‌ای با Promptهای قابل آزمون

  1. UI و Navigation را با داده ساختگی بسازید.
  2. Schema را تأیید و را متصل کنید.
  3. Email Login را فعال و تأیید ایمیل را روشن کنید.
  4. نقش و دسترسی سطح رکورد را در Backend اعمال کنید.
  5. CRUD پروژه و پیام را مرحله‌ای اضافه کنید.
  6. Reset Password و Redirect را تنظیم کنید.
  7. Upload امن و محدود را در مرحله مستقل بسازید.
  8. را وصل و تغییرها را در Branch بازبینی کنید.
  9. پس از Smoke Test روی Hosting منتشر کنید.

بعد از هر مرحله Version History یا Commit سالم داشته باشید. تاریخچه کد جای Backup پایگاه داده را نمی‌گیرد. مستندات Bolt صریحاً می‌گوید بازگردانی Version History لزوماً متصل به Supabase را Restore نمی‌کند.

Bolt یا Supabase؟

برای پروژه جدید، Bolt مسیر ساده‌تری است و بدون حساب ثالث آماده می‌شود. اگر تیم Supabase موجود، کنترل پیشرفته یا داده قبلی دارد، اتصال Supabase منطقی است. اتصال جدید به پروژه‌ای که از قبل Bolt دارد می‌تواند جایگزینی اتصال و خطر از دست رفتن داده ایجاد کند؛ قبل از هر تغییر Export و Backup بگیرید.

معیارBolt Supabase
شروعیکپارچه و سریعنیازمند اتصال حساب
کنترل بیرون Boltمدیریت در BoltDashboard مستقل
پروژه موجودمناسب شروع تازهمناسب زیرساخت قبلی
Restoreسیاست Backup را بررسی کنیدVersion History کد را Restore نمی‌کند
ریسک تغییر اتصالکم در شروعجایگزینی بدون Backup خطرناک است

و Reset Password

در تنظیمات می‌توانید 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 FunctionComponent مرورگر
ذخیرهSecrets settingsفایل Commit‌شده
دسترسی تیمEditor یا Co-owner ضروریاشتراک گسترده
Logماسک‌شدهچاپ Header و Token
Rotationمنظم و پس از Incidentکلید قدیمی دائمی

برای معماری اتصال امن ابزارها و سرویس‌ها، راهنمای MCP Server را ببینید. هر Integration باید Scope حداقلی و امکان Revoke داشته باشد.

و قابلیت خروج از Bolt

اتصال تاریخچه کامل و امکان ادامه توسعه بیرون Bolt را فراهم می‌کند. Repository اولیه Private و روی main ساخته می‌شود. برای Feature جدید Branch جدا بسازید و پیش از Merge، Diff و Build را Review کنید.

  • Repository را در Organization کسب‌وکار ایجاد کنید.
  • Branch Protection و Pull Request اجباری باشد.
  • Secret و فایل Environment وارد Git نشود.
  • Dependency جدید از نظر مجوز و امنیت بررسی شود.
  • مالک و مالک Bolt یک فرد موقت نباشد.

در پروژه مشترک، دسترسی Collaborator به داده و Integration را جدی بگیرید. Viewer به Environment Variable دسترسی ندارد، اما Editor و Co-owner می‌توانند سطح بالاتری داشته باشند. نقش تیم را با اصل کمترین دسترسی تنظیم و دوره‌ای بازبینی کنید.

تست امنیت پیش از انتشار

سه حساب آزمایشی Client، Staff و Admin بسازید. فقط Happy Path را اجرا نکنید؛ URL مستقیم، Request دستکاری‌شده، Session منقضی و Upload نامعتبر را هم آزمایش کنید.

  1. Client A تلاش کند Project متعلق به Client B را باز کند.
  2. Staff شناسه Assignee را در Request تغییر دهد.
  3. کاربر مهمان URL فایل را مستقیم درخواست کند.
  4. Reset Password از دامنه غیرمجاز امتحان شود.
  5. فایل بزرگ یا پسوند جعلی Upload شود.
  6. قطع و پیام خطای عمومی بررسی شود.
  7. Secret در Source و Network Response جست‌وجو شود.

از اطلاعات واقعی مشتری برای Test استفاده نکنید. داده مصنوعی با همان ساختار بسازید و قبل از Publish پاک‌سازی کنید.

Publish روی Bolt Hosting

پروژه‌های جدید به‌طور پیش‌فرض از Bolt Hosting استفاده می‌کنند و امکان Domain سفارشی دارند. پیش از Publish، Build، ، و Secretهای محیط Production را بررسی کنید. URL ساخته‌شده را در پنجره ناشناس باز کنید.

  1. Environment تولید را از Preview جدا کنید.
  2. Migration و Backup را تأیید کنید.
  3. Site URL و Redirectهای Auth را به دامنه نهایی تغییر دهید.
  4. Smoke Test ورود، پروژه و پیام را اجرا کنید.
  5. SSL، Mobile و خطاهای Console را بررسی کنید.
  6. Log، مصرف و هزینه را پایش کنید.
  7. نسخه سالم برای Rollback نگه دارید.

اشتباه‌های رایج

  • ساخت همه قابلیت‌ها در یک Prompt: Review و یافتن علت خطا دشوار می‌شود.
  • اعتماد به مخفی شدن Button: Request مستقیم می‌تواند مجوز ناقص را دور بزند.
  • باقی ماندن localhost در Site URL: Login و Reset روی دامنه زنده خراب می‌شود.
  • قرار دادن Secret در Frontend: مقدار در دستگاه کاربر دیده می‌شود.
  • اتکا به Version History برای : تاریخچه کد Backup داده نیست.
  • انتشار با داده واقعی آزمایشی: Preview به نشت اطلاعات تبدیل می‌شود.

جمع‌بندی

می‌تواند مسیر Prompt تا اپ Full-Stack را کوتاه کند، به‌خصوص وقتی ، Login و Hosting را در یک محیط می‌خواهید. نتیجه قابل اعتماد از Prompt مرحله‌ای، Schema کوچک و تست مجوز به‌دست می‌آید.

برای پورتال مشتری، امنیت مهم‌تر از ظاهر Dashboard است. مالکیت رکورد را در Backend بررسی کنید، Redirectهای Auth را محدود نگه دارید، Secret را فقط در Server Function بخوانید و کد را در Review کنید.

امروز نسخه UI پورتال را فقط با Mock Data و سه نقش بسازید؛ پیش از اتصال ، ماتریس دسترسی را تأیید و سناریوی دسترسی Client A به پروژه Client B را به تست‌ها اضافه کنید.

منابع رسمی