The latest articles on DEV Community by KouroX | کوروکس (@kourox-org). https://dev.to/kourox-org https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4189202%2Fd8d08c98-1202-4b6e-96f3-ad6ef7ef4584.png https://dev.to/kourox-org en KouroX | کوروکس Tue, 27 Oct 2026 09:38:23 +0000 https://dev.to/kourox-org/trhy-frm-pshtybny-khyf-pwl-bdwn-jmawry-tlt-mhrmnh-4217 https://dev.to/kourox-org/trhy-frm-pshtybny-khyf-pwl-bdwn-jmawry-tlt-mhrmnh-4217 <p>وقتی کاربر می‌گوید «تراکنشم نرسیده»، طراحی فرم پشتیبانی تعیین می‌کند چه اطلاعاتی ارسال کند. یک کادر آزاد با عنوان «تمام جزئیات را بنویسید» ممکن است باعث ارسال ناخواستهٔ رمز، عبارت بازیابی یا تصویر اطلاعات شخصی شود.</p> <p>این یک پیشنهاد طراحی برای جمع‌آوری اطلاعات لازم و کاهش افشای اطلاعات اضافی است.</p> <p>۱. سؤال‌های مشخص بپرسیم</p> <p>برای بررسی اولیهٔ یک مشکل تراکنش، فرم می‌تواند این فیلدها را داشته باشد:</p> <ul> <li>نام کیف پول یا سرویس</li> <li>نام شبکه و دارایی</li> <li>وضعیت نمایش‌داده‌شده: Pending، Failed یا تأییدشده</li> <li>شناسهٔ تراکنش، در صورت وجود</li> <li>متن خطا، بدون اطلاعات محرمانه</li> </ul> <p>شناسهٔ تراکنش را اجباری نکنیم؛ ممکن است برداشت هنوز از طرف صرافی به شبکه ارسال نشده باشد.</p> <p>۲. هشدار را کنار محل ورود اطلاعات قرار دهیم</p> <p>بالای کادر توضیحات و بخش ارسال تصویر، این پیام را نمایش دهیم:</p> <p>«عبارت بازیابی، کلید خصوصی، رمز عبور و کد ورود را ارسال نکنید. برای بررسی وضعیت تراکنش به این اطلاعات نیازی نداریم.»</p> <p>هشدار کوتاه کنار فیلد، هنگام تصمیم کاربر دیده می‌شود؛ نباید فقط در صفحهٔ قوانین پنهان باشد.</p> <p>۳. حریم خصوصی اطلاعات عمومی را هم در نظر بگیریم</p> <p>آدرس کیف پول و شناسهٔ تراکنش می‌توانند فعالیت مالی قابل مشاهده را به هویت فرد مرتبط کنند. بنابراین پیشنهاد می‌کنم:</p> <ul> <li>درخواست‌های پشتیبانی به‌صورت پیش‌فرض عمومی نباشند.</li> <li>پیش از ارسال تصویر، امکان بازبینی و پوشاندن اطلاعات شخصی وجود داشته باشد.</li> <li>متن کامل درخواست‌ها وارد ابزارهای تحلیل رفتار و گزارش‌های خطای عمومی نشود.</li> <li>دسترسی کارکنان و مدت نگهداری اطلاعات مشخص و محدود باشد.</li> </ul> <p>۴. طراحی را با دادهٔ ساختگی آزمایش کنیم</p> <p>پیش از انتشار فرم، بررسی کنیم: آیا پیام‌های خطا دادهٔ واردشده را بازتاب می‌دهند؟ آیا پیوست‌ها ناخواسته عمومی‌اند؟ آیا کاربر می‌فهمد چه اطلاعاتی را نباید ارسال کند؟</p> <p>فرم خوب باید مسیر کمک‌گرفتن را روشن کند، بدون اینکه کاربر را به افشای اطلاعات بیشتری از نیاز واقعی سوق دهد.</p> <p>منبع تکمیلی: "راهنمای امنیت Ethereum" (<a href="https://ethereum.org/security/" rel="noopener noreferrer">https://ethereum.org/security/</a>)</p> <p>شفافیت تولید محتوا: این پیش‌نویس با هوش مصنوعی تولید شده است.</p> security webdev privacy ux