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

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

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

چرا نقش‌های پیش‌فرض وردپرس کافی نیستند؟

وردپرس شش نقش پیش‌فرض دارد که حول مدیریت محتوا ساخته شده‌اند. در سایت مشاوره، این نقش‌ها با شکاف‌های زیر روبه‌رو می‌شوند:

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

در سایت مشاوره، متن گفتگو حساس‌ترین داده یک پلتفرم است؛ حتی لاگ‌های فنی هم نباید آن را ثبت کنند.

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

نقش‌های ضروری در سایت مشاوره

مراجع (Client)

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

مشاور (Counselor)

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

سرپرست حرفه‌ای (Professional Supervisor)

مشاهده یادداشت‌های مشاوران زیرمجموعه، اما فقط با رضایت صریح مراجع و در بازه مشخص.

مدیر پذیرش (Intake Officer)

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

مدیر پلتفرم (Platform Manager)

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

چالش‌های داده مشاوره

پیش از ورود به پیاده‌سازی، باید چالش‌های خاص داده مشاوره را دقیق بشناسیم.

۱. محرمانگی مطلق گفتگو

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

۲. رابطه دوتایی مشاور-مراجع

رابطه مشاوره دوتایی است. مدل نقش وردپرس بر پایه گروه‌بندی است، نه بر پایه رابطه دوتایی. برای پر کردن این شکاف، باید از یک لایه واسط استفاده شود. مطلب پیاده‌سازی درست Custom Post Type نقطه شروع مناسبی است.

۳. لاگ فنی بدون نشت محتوا

هر خطای فنی ممکن است متن گفتگو را در لاگ ثبت کند. این یعنی باید یک لایه Sanitization برای لاگ‌ها داشته باشیم. مطلب پاک‌سازی داده‌ها در کدنویسی وردپرس راهنمای دقیقی است.

۴. رضایت آگاهانه

هر دسترسی به گفتگو باید مبتنی بر رضایت آگاهانه باشد. رضایت باید قابل لغو و قابل ردیابی باشد. این نیازمند یک جدول Consent با تاریخچه کامل است.

۵. قرارداد مشاوره

هر گفتگو بخشی از یک قرارداد مشاوره است. دسترسی باید در چارچوب این قرارداد و بازه زمانی آن تعریف شود. برای مطالعه بیشتر، مطلب فیلدهای سفارشی ACF برای ساختاردهی قرارداد مفید است.

تنظیمات مشاوره‌ای برای هر نقش

نقش دسترسی گفتگو یادداشت مشاور رضایت
مراجع گفتگوی شخصی مشاهده خلاصه ثبت و لغو
مشاور مراجعان تخصیصی ثبت و ویرایش دریافت
سرپرست حرفه‌ای زیرمجموعه با رضایت مشاهده مشاهده رضایت
مدیر پذیرش خیر خیر ثبت اداری
مدیر پلتفرم گزارش تجمیعی خیر مشاهده تجمیعی

پیاده‌سازی با PHP

ابتدا CPT جلسه مشاوره را می‌سازیم. برای مطالعه بیشتر، مطلب پیاده‌سازی درست Custom Post Type را ببینید.

function wk_register_counseling_session_cpt() {
    register_post_type('wk_counseling_session', array(
        'label' => 'جلسات مشاوره',
        'public' => false,
        'show_ui' => true,
        'capability_type' => 'wk_counseling_session',
        'capabilities' => array(
            'read_post' => 'read_wk_counseling_session',
            'edit_post' => 'edit_wk_counseling_session',
            'edit_posts' => 'edit_wk_counseling_sessions',
            'edit_others_posts' => 'edit_others_wk_counseling_sessions',
        ),
        'map_meta_cap' => true,
        'supports' => array('title', 'author', 'custom-fields'),
    ));
}
add_action('init', 'wk_register_counseling_session_cpt');

سپس نقش‌های سفارشی را می‌سازیم. برای درک بهتر هوک‌ها، مطلب هوک‌های وردپرس: قلب تپنده توسعه را ببینید.

function wk_register_counseling_roles() {
    add_role('wk_counseling_client', 'مراجع مشاوره', array(
        'read' => true,
        'read_own_counseling_session' => true,
        'read_own_invoices' => true,
        'manage_own_consent' => true,
    ));

    add_role('wk_counselor', 'مشاور', array(
        'read' => true,
        'edit_wk_counseling_sessions' => true,
        'edit_others_wk_counseling_sessions' => true,
        'read_wk_counseling_notes' => true,
        'edit_wk_counseling_notes' => true,
        'schedule_wk_counseling_sessions' => true,
    ));

    add_role('wk_professional_supervisor', 'سرپرست حرفه‌ای', array(
        'read' => true,
        'read_wk_counseling_notes' => true,
        'review_wk_counseling_sessions' => true,
    ));

    add_role('wk_intake_officer', 'مدیر پذیرش', array(
        'read' => true,
        'assign_wk_counselors' => true,
        'manage_wk_schedules' => true,
    ));
}
add_action('init', 'wk_register_counseling_roles');

برای محافظت از فرم‌ها در برابر CSRF، مطلب نانس وردپرس و امنیت فرم و درخواست AJAX را ببینید.

گفتگوی محرمانه و رمزنگاری

متن گفتگو باید با AES-256-GCM و کلید اختصاصی هر مشاور رمزنگاری شود:

function wk_save_counseling_message($session_id, $counselor_id, $message) {
    if (!current_user_can('edit_wk_counseling_notes')) {
        return new WP_Error('forbidden', 'دسترسی غیرمجاز');
    }
    $key = wk_get_counselor_key($counselor_id);
    $iv = random_bytes(12);
    $tag = '';
    $cipher = openssl_encrypt($message, 'aes-256-gcm', $key, OPENSSL_RAW_DATA, $iv, $tag);
    add_post_meta($session_id, 'wk_cipher', base64_encode($cipher));
    add_post_meta($session_id, 'wk_iv', base64_encode($iv));
    add_post_meta($session_id, 'wk_tag', base64_encode($tag));
}

نکته کلیدی: کلید رمزنگاری هر مشاور باید در یک Vault جدا ذخیره شود، نه در دیتابیس وردپرس. اگر کلید در همان دیتابیس باشد، رمزنگاری بی‌اثر است. برای مطالعه بیشتر درباره رمزنگاری دیتابیس، مطلب رمزنگاری دیتابیس را ببینید.

همچنین برای پشتیبان‌گیری امن از داده مشاوره، مطلب پشتیبان‌گیری امن از دیتابیس راهنمای دقیقی است. در نهایت، مطلب انطباق با GDPR در پروژه وردپرس چارچوب قانونی این حوزه را مشخص می‌کند.

امنیت و حریم خصوصی

سه لایه امنیتی ضروری است:

  1. رمزنگاری گفتگو با کلید اختصاصی هر مشاور.
  2. ثبت رضایت آگاهانه مراجع و لاگ کامل هر دسترسی.
  3. احراز هویت چندلایه برای همه نقش‌ها، بدون استثنا.

برای امن‌سازی نشست‌های کاربری، مطلب امن‌سازی نشست‌های کاربری را ببینید. برای فعال‌سازی احراز هویت دو مرحله‌ای، مطلب فعال‌سازی احراز هویت دو مرحله‌ای 2FA راهنمای عملی است. برای امن‌سازی ورود ادمین، مطلب امن‌سازی ورود ادمین وردپرس را ببینید.

مرجع حرفه‌ای این حوزه در ویکی‌پدیا، مقاله List of counseling topics مرور خوبی از شاخه‌های مختلف مشاوره ارائه می‌دهد.

پرسش‌های پرتکرار درباره تنظیمات نقش مشاوره

آیا می‌توانم از نقش Author برای مشاور استفاده کنم؟

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

چگونه محرمانگی گفتگو را در لاگ‌های فنی حفظ کنم؟

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

آیا سرپرست حرفه‌ای باید به گفتگو دسترسی داشته باشد؟

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

چگونه داده پرداخت را از مشاور جدا کنم؟

با نگهداری داده پرداخت در CPT جداگانه و نقش اختصاصی. مشاور فقط به فاکتور خودش دسترسی داشته باشد.

آیا End-to-End Encryption برای مشاوره لازم است؟

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

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

اشتباه پیامد راه‌حل
نقش یکسان برای همه مشاوران نشت گفتگو بین مشاوران Capability اختصاصی + تخصیص دینامیک
ذخیره متن گفتگو به‌صورت متن ساده نشت داده گفتگو رمزنگاری با کلید اختصاصی
ثبت متن گفتگو در لاگ فنی نقض محرمانگی از مسیر پشتی Sanitization لاگ پیش از ثبت
نبود لاگ دسترسی عدم امکان ممیزی ثبت هر دسترسی در جدول اختصاصی
نبود رضایت قابل لغو نقض حقوق مراجع سیستم Consent با تاریخچه کامل

نگاه معماری در سطح سیستم‌های مشاوره

در سطح معماری، سایت مشاوره با یک چالش بنیادین روبه‌روست: گفتگو یک داده سریع‌الانتشار است که هم‌زمان در چند لایه ظاهر می‌شود: دیتابیس، Cache، لاگ، Backup. برای حفظ محرمانگی، باید تمام این لایه‌ها رمزنگاری یا Sanitize شوند.

رویکرد پیشنهادی، معماری «Data Privacy Mesh» است. هر لایه داده مستقل رمزنگاری می‌شود و کلید اختصاصی دارد. این یعنی حتی اگر یک لایه نفوذ شود، داده لایه‌های دیگر فاش نمی‌شود. این معماری، مشابه رویکردهای حرفه‌ای در پلتفرم‌های سلامت دیجیتال است.

نکته دوم، بحث «Zero-Knowledge Message» است. برای گفتگوی متنی حساس، باید پیام‌ها سمت کاربر رمزنگاری شوند و سرور فقط Ciphertext را ببیند. این نیازمند یک لایه JavaScript برای رمزنگاری و یک کلید مشترک بین مشاور و مراجع است.

نکته سوم، بحث «Consent-Dependent Decryption» است. کلید رمزنگاری گفتگو باید فقط تا زمانی معتبر باشد که رضایت مراجع فعال است. اگر مراجع رضایت خود را لغو کند، کلید نیز باید باطل شود. این نیازمند یک KMS (Key Management System) پویا است.

پیشنهادهای عملی برای پیاده‌سازی

سه توصیه عملی که در پروژه‌های واقعی مؤثر بوده‌اند:

  1. کلید رمزنگاری را در یک Vault جدا (مثل HashiCorp Vault) نگهداری کنید، نه در دیتابیس.
  2. هر دسترسی را در یک لاگ تغییرناپذیر ثبت کنید تا در صورت شکایت، قابل ارائه باشد.
  3. یک Endpoint عمومی برای تأیید رضایت طراحی کنید تا مراجع هر زمان بتواند وضعیت دسترسی‌ها را ببیند.

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