بازار حرفه‌ای ترمیتجزئیات پروژه

پیش از ارسال پیشنهاد، نیاز پروژه را دقیق بخوان

پرداخت امن و همکاری شفاف
بازگشت به بازار پروژه‌ها
طراحی و توسعه وب منتخب ترمیت

دریافت و فیلتر پیام گروه‌های بله

ربات ترمیت

بودجه پروژه۳٬۰۰۰٬۰۰۰ تا ۷٬۰۰۰٬۰۰۰تومان
مهلت انجامتوافقی
پیشنهادهای ثبت‌شده۰ پیشنهاد
مدل پرداختامن و مرحله‌ای
شرح کامل پروژه

دقیقاً چه کاری باید انجام شود؟

شرح پروژه: دریافت و فیلتر پیام گروه‌های بله

هدف

ساخت یک سرویس مستقل برای اتصال به حساب شخصی کاربر در پیام‌رسان بله، دریافت پیام‌های جدید گروه‌های انتخاب‌شده و استخراج پیام‌های منطبق با قوانین برای استفاده بعدی در اپلیکیشن کاربر.

اتصال واتساپ کاربر با Baileys از قبل وجود دارد؛ این پروژه فعلاً نباید به آن متصل شود یا کد آن را تغییر دهد.

تصمیم اصلی

مسیر مطلوب حساب شخصی است، نه Bot API یا توکن بازو.

در بسیاری از گروه‌های هدف اجازه افزودن ربات وجود ندارد.

الگوی معماری Baileys مدنظر است، اما کد و پروتکل واتساپ مستقیماً برای بله کاربرد ندارد.

استفاده از کتابخانه موجود پس از بررسی کیفیت و محدودیت‌های آن قابل پیشنهاد است؛ وابستگی‌ها باید شفاف باشند و محصول مبتنی بر کتابخانه دیگر به‌عنوان پیاده‌سازی مستقل از صفر معرفی نشود.

مرحله صفر: اثبات امکان اجرا

پیش از توسعه داشبورد کامل، مسیر واقعی ورود حساب شخصی و دریافت پیام بررسی شود.

مستندات Bot API را نباید به‌عنوان مستندات حساب شخصی استفاده کرد.

منابع، نسخه وابستگی‌ها و محدودیت‌ها ثبت شوند.

اولین خروجی قابل قبول: ورود واقعی کاربر، ذخیره امن نشست، اجرای دوباره با همان نشست در صورت معتبر بودن، و دریافت یک پیام جدید از یک گروه مجاز.

اگر این مسیر ممکن یا پایدار نیست، مانع با شواهد اعلام شود؛ داده ساختگی یا صرف ایجاد فایل نشست اثبات اتصال نیست.

امکانات نسخه اولیه

  • ورود با شماره و کد در محیط محلی؛ نوع تحویل کد و فرمت شماره مطابق سازوکار واقعی بله بررسی شود.
  • ذخیره امن نشست و استفاده مجدد از آن؛ ورود مجدد فقط در صورت انقضا، لغو یا نیاز واقعی.

ماندگاری همیشگی تضمین نشود.

  • انتخاب چند گروه متعلق به حساب کاربر.

فقط گروه‌ها در محدوده‌اند؛ کانال‌ها و گفت‌وگوهای خصوصی پردازش نشوند.

  • فهرست مجاز صریح برای گروه‌ها؛ وقتی فهرست خالی است دریافت عملیاتی و پردازش همه گفتگوها فعال نشود.
  • دریافت پیام‌های جدید و ثبت شناسه پیام، شناسه گروه، زمان، متن و اطلاعات لازم برای فیلتر.

اطلاعات فرستنده فقط به اندازه نیاز و دسترسی واقعی.

  • فیلتر ساده بر اساس کلمات یا عبارت‌ها در نسخه اول؛ جزئیات منطق تطبیق با کاربر نهایی شود.

طراحی امکان افزودن قوانین دیگر را داشته باشد.

  • نمایش پیام‌های منطبق در خروجی محلی برای تست.

قرارداد خروجی برای اتصال آینده به اپلیکیشن تعریف شود؛ فعلاً ارسال خارجی و فوروارد بین گروه‌ها لازم نیست.

  • جلوگیری از پردازش تکراری پیام‌ها و مدیریت قطع اتصال، تلاش مجدد با فاصله مناسب و نمایش خطای قابل فهم.
  • پنل ساده فارسی برای وضعیت ورود، اتصال، انتخاب گروه‌ها، تنظیم قوانین، شروع/توقف و مشاهده نتایج.

پس از اثبات اتصال ساخته شود.

معماری پیشنهادی

لایه اتصال و مدیریت نشست از لایه دریافت رویداد، یکسان‌سازی پیام، فهرست گروه‌های مجاز، موتور قوانین و خروجی جدا باشد.

پنل فقط از سرویس محلی استفاده کند و منطق اتصال در رابط گرافیکی قرار نگیرد.

جزئیات پروتکل پشت یک رابط مشخص پنهان شود تا تعویض کتابخانه ممکن باشد.

انتخاب زبان و فناوری بر اساس شواهد اتصال انجام شود؛ الزام قطعی به زبان خاصی وجود ندارد.

تجربه کاربری

کاربر برنامه‌نویس حرفه‌ای نیست.

نصب و اجرا باید ساده و مرحله‌به‌مرحله باشد.

ورود، انتخاب گروه و وضعیت واقعی با متن فارسی روشن نمایش داده شود.

فیلد شماره و مقادیر فنی چپ‌به‌راست باشند.

به‌روزرسانی دوره‌ای نباید مقدار ورودی در حال تایپ را پاک کند.

وضعیت «متصل» فقط پس از پاسخ معتبر از سرویس نمایش داده شود.

ذخیره تنظیمات، اجرای فرایند و اتصال موفق سه وضعیت متفاوت‌اند.

امنیت و محدودیت‌ها

شماره، کد ورود، توکن و محتوای نشست در لاگ یا فایل تحویل عمومی قرار نگیرند.

کد در همان محیط محلی وارد شود.

نشست با سازوکار امن سیستم‌عامل نگهداری شود.

دسترسی فقط برای حساب و گروه‌های مجاز کاربر باشد؛ دور زدن احراز هویت یا دسترسی گروه‌ها جزو پروژه نیست.

در صورت استفاده از پروتکل یا SDK غیررسمی، ریسک تغییر سرویس، نگهداری و محدودیت حساب توضیح داده شود.

وضعیت کار قبلی؛ نیازمند بررسی مستقل

یک نمونه مبتنی بر بات و داشبورد محلی قبلاً ساخته شد، اما با هدف نهایی حساب شخصی یکسان نیست.

نمونه جدیدی نیز با کتابخانه غیررسمی حساب شخصی تهیه شده است.

طبق گزارش اجرا، تست‌های محلی فیلتر و ذخیره رمزگذاری‌شده نشست انجام شده و فایل نشست وجود دارد.

اتصال معتبر با نشست و دریافت پیام واقعی هنوز تأیید نشده است.

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

کد موجود صرفاً مرجع اولیه است، نه محصول آماده.

مراحل تحویل و معیار پذیرش

گزارش امکان‌سنجی مستند و نمونه ورود واقعی با حساب شخصی؛ اگر غیرممکن است گزارش مانع به جای داشبورد نمایشی.

دریافت یک پیام واقعی از گروه آزمایشی انتخاب‌شده و نمایش محلی آن، با حفظ اطلاعات محرمانه.

توقف و اجرای دوباره با نشست معتبر بدون دریافت کد غیرضروری؛ اعلام واضح نشست نامعتبر.

فیلتر گروه‌ها و قوانین: پیام گروه خارج از فهرست وارد خروجی نشود؛ فهرست خالی همه گروه‌ها را مجاز نکند؛ پیام منطبق و نامنطبق نتیجه صحیح بدهند.

آزمون قطع و وصل و جلوگیری از تکرار، همراه با گزارش محدودیت پیام‌های ازدست‌رفته در زمان قطع اتصال.

تحویل سورس، وابستگی‌های نسخه‌بندی‌شده، نمونه تنظیمات بدون راز، راهنمای نصب و اجرا، معماری، تست‌ها، محدودیت‌ها و قرارداد خروجی آینده.

مواردی که پیش از برآورد نهایی مشخص شوند

تعداد گروه‌ها و حجم پیام، قواعد دقیق تطبیق، نیاز به متن یا رسانه، مدت نگهداری خروجی و محل استقرار نهایی.

برای تست اولیه، یک گروه و پیام متنی کافی است.

هزینه و زمان مرحله اثبات اتصال جدا از تکمیل محصول برآورد شود.

مهارت‌های موردنیاز

Pythonپایتون برای داده