پرش به مطلب اصلی

از بازدیدکنندگان بخواهید وارد شوند

هدف​

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

پیش از شروع​

  • درگاهی که پیش‌تر منتشر کرده‌اید. ببینید یک برنامه را به‌عنوان درگاه منتشر کنید.
  • کسی که نصب پارس‌ور شما را اداره می‌کند ارسال ایمیل را راه انداخته باشد. ثبت‌نام یک پیوند تأیید می‌فرستد، و بدون ایمیل هیچ‌کس نمی‌تواند ساختن حساب را به پایان برساند.

گام‌ها​

۱. راه‌حل خود را باز کنید، درگاه‌ها را انتخاب کنید و درگاه را باز کنید. ۲. چه کسی می‌تواند بازش کند را از هر کسی به کسانی که وارد می‌شوند تغییر دهید. ۳. ذخیره را بزنید.

همین. نفر بعدی که نشانی را باز کند به‌جای برنامهٔ شما یک فرم ورود می‌بیند.

بازدیدکننده چه می‌بیند​

یک فرم ورود، و تا وارد نشده باشد هیچ‌چیز از برنامهٔ شما. صفحه‌های شما پشت آن کشیده نمی‌شوند — خودِ صفحه همان فرم است.

اگر چیز دیگری نگویید، فرم از آنِ پلتفرم است و عمداً ساده. اگر می‌خواهید شبیه باقی سایت‌تان باشد — و صفحهٔ اصلی برای همه باز بماند — می‌توانید خودتان بکشیدش: ببینید صفحهٔ ورود خودتان را بکشید.

از آن فرم کسی می‌تواند:

  • وارد شود، با نشانی و گذرواژه‌ای که همین‌جا دارد.
  • حساب بسازد. نام، نشانی و گذرواژه را پر می‌کند — گذرواژه را دو بار، تا یک اشتباه تایپی او را از حسابی که همین حالا ساخته بیرون نگذارد — و ما پیوندی برایش ایمیل می‌کنیم. هنوز وارد نشده است — پیوند را باز می‌کند، بعد وارد می‌شود.
  • کد وارد کند، اگر برنامهٔ احرازکننده را روشن کرده باشد. فرم فقط وقتی کد می‌خواهد که حساب یکی داشته باشد.
  • بگوید گذرواژه‌اش را فراموش کرده و پیوندی برای انتخاب گذرواژهٔ تازه بگیرد. پایین‌تر را ببینید.
پیوند به درِ ورودی خودِ درگاه شما برمی‌گردد

پیوند تأیید روی نشانی خودِ درگاه شما می‌نشیند، نه روی صفحه‌ای جدا — و پیوند بازنشانی گذرواژه هم همین‌طور. پس اگر کسی یکی از آن‌ها را از صندوق ورودی‌اش دنبال کند، با همان فرمِ درست به درگاه شما می‌رسد.

به همین دلیل می‌توانید صفحه‌ای با هر نامی که خواستید بکشید — پلتفرم /confirm-email، /reset-password یا هیچ نام دیگری را برای خودش نگه نمی‌دارد.

اگر کسی گذرواژه‌اش را فراموش کند​

روی گذرواژه‌تان را فراموش کرده‌اید؟ در فرم ورود می‌زند، نشانی‌اش را می‌دهد و ما پیوندی برایش ایمیل می‌کنیم. پیوند او را به درگاه شما بازمی‌گرداند، دو بار گذرواژهٔ تازه می‌خواهد و سپس او را برای ورود با همان گذرواژه می‌فرستد.

چیزی نیست که شما بسازید و کاری نیست که بکنید. این در یک درگاه بیش از هر جای دیگری اهمیت دارد: پشتِ درگاه شما هیچ میز پشتیبانیِ ما نیست، و شما نمی‌توانید گذرواژهٔ یک بازدیدکننده را بازنشانی کنید — پس این تنها راه بازگشت اوست و باید بدون پرسیدن از کسی کار کند.

ما هرگز نمی‌گوییم آیا نشانی‌ای حساب دارد یا نه

صفحه چه حسابی برای آن نشانی باشد و چه نباشد، یک پاسخ می‌دهد: «اگر حسابی با آن نشانی باشد، پیوندی در راه است.»

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

با ذخیرهٔ گذرواژهٔ تازه دو چیز رخ می‌دهد و دانستن هر دو می‌ارزد:

  • هر نشستی که آن حساب داشته پایان می‌یابد — روی همهٔ دستگاه‌ها، نه فقط دستگاهی که با آن کار می‌کند. گذرواژه یا فراموش شده است یا کس دیگری آن را دارد، و این پاسخ به حالت دوم است.
  • نشانی‌اش تأییدشده به حساب می‌آید، چون پیوند به صندوق او رفت و برگشت. پس کسی که ثبت‌نام کرده، پیام تأیید را هرگز باز نکرده و بعد گذرواژه‌اش را بازنشانی کرده، می‌تواند وارد شود.

کسی که گذرواژه‌اش را هنوز می‌داند و فقط گذرواژهٔ دیگری می‌خواهد از همین راه می‌رود: در یک درگاه «تغییر گذرواژه» وجود ندارد.

اگر کسی به یک شرکت دعوت شود​

یک حساب پورتال می‌تواند به یک شرکت تعلق داشته باشد، و کسی با دعوت‌شدن به آن وارد می‌شود. پیام حاوی یک پیوند است، و آن پیوند روی در ورودی پورتال شما فرود می‌آید — همان نشانی پیوند تأیید نشانی و پیوند بازنشانی گذرواژه. پورتال خودش آن را رسیدگی می‌کند:

  • کسی که از پیش وارد شده است بی‌درنگ می‌پیوندد و به او گفته می‌شود به کدام شرکت پیوسته است.
  • کسی که وارد نشده فرم ورود را با عنوان شما دعوت شده‌اید می‌بیند. وارد می‌شود — یا اول حساب می‌سازد و نشانی‌اش را تأیید می‌کند — و دعوت هنگام بازگشت هنوز منتظر اوست. هرگز لازم نیست دوباره سراغ پیام برود.

پیوستن، پاسخ صفحه‌های شما را بی‌درنگ عوض می‌کند: نشست برای همان شرکت دوباره صادر می‌شود، پس portalCustomerId() از همان خواندن بعدی آن را برمی‌گرداند.

دعوت فقط برای همان نشانی‌ای کار می‌کند که برایش فرستاده شده

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

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

دعوت‌کردن را شما می‌کشید و فراخوانش از آنِ پلتفرم است

مالک یک شرکت، همکارانش را از صفحه‌ای دعوت می‌کند که شما کشیده‌اید: یک جعبه‌ی متن، یک دکمه و invitePerson(...). هیچ صفحه‌ی «افراد»ی درون پلتفرم نیست، و خود دعوت عملیات رکورد نیست — یکی از شش فراخوانی است که پلتفرم می‌دهد، چون هیچ API سفارشی نمی‌تواند آن‌ها را انجام دهد. ببینید بگذارید بازدیدکنندگان شرکت خودشان را اداره کنند.

وقتی کسی وارد شد، صفحه‌های شما چه می‌توانند بکنند​

نشان‌دادن اینکه او کیست. نوشته‌ای که به user.name یا user.email مقید باشد فرد واردشده را نشان می‌دهد، دقیقاً همان‌طور که در برنامه‌ای درون پلتفرم. تصویری مقید به user.photo عکس او را نشان می‌دهد اگر داشته باشد. همان نقشه در هر دو جا کار می‌کند — نسخهٔ جداگانه‌ای برای درگاه نمی‌کشید.

اجازهٔ خروج. دکمه‌ای که کنشش خروج است نشست را پایان می‌دهد و او را به درِ ورودی درگاه شما برمی‌گرداند. در درگاهی که هر کسی می‌تواند بازش کند، آن دکمه به‌جای این کار یک مشکل گزارش می‌دهد، چون چیزی برای خارج‌شدن از آن نیست.

نشان‌دادن رکوردهای خودِ هر کس. این هدفِ ورود است، و در Custom API شما رخ می‌دهد، نه روی صفحه. وقتی بازدیدکنندهٔ واردشده صفحه‌ای را بار می‌کند، هویتش همراه درخواست می‌رود و اسکریپت API شما می‌تواند آن را بخواند:

// چه کسی می‌پرسد — از نشست خودش خوانده می‌شود، هرگز از درخواست.
var customerId = portalCustomerId();

// فقط سفارش‌های شرکتی که او عضوش است.
var rows = runQuery({
entity: 'par_order',
select: ['par_name', 'par_placed_on', 'par_amount'],
filter: { connector: 'And', conditions: [
{ field: 'par_customer', operator: 'Equals', value: customerId }
] }
});

setOutput('rows', rows);
setOutput('total', rows.length());

portalCustomerId() شرکت را از نشست خودِ بازدیدکننده می‌خواند. هیچ راهی نیست که صفحه شرکت دیگری به شما بفرستد، و همین است که مشتری الف را از رکوردهای مشتری ب دور نگه می‌دارد.

فیلتر با شماست، و هیچ‌چیز بررسی نمی‌کند که نوشته‌ایدش

API‌ای که فیلتر نکند، هر ردیف را به هر بازدیدکنندهٔ واردشده می‌دهد. وارد کردن کسی به شما می‌گوید او کیست؛ آنچه اسکریپت شما برمی‌گرداند را تنگ نمی‌کند.

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

چه کسی می‌تواند حساب بسازد​

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

اینکه آن حساب آنگاه چه ببیند هر چیزی است که Custom API‌های شما برای کسی بی‌شرکت پاسخ می‌دهند — که اگر اسکریپت‌هایتان مثل نمونهٔ بالا فیلتر کنند، هیچ است. و این پیش‌فرض درست است: غریبه‌ای که حساب دارد باز هم غریبه است.

خاموش‌کردن دوباره​

چه کسی می‌تواند بازش کند را به هر کسی برگردانید و ذخیره کنید. نشانی دوباره مستقیم به برنامهٔ شما باز می‌شود، و هر نشستی که کسی داشت بی‌درنگ از اعتبار می‌افتد — هیچ‌چیز ورود قدیمی را در درگاهی که دیگر ورود ندارد محترم نمی‌شمارد.

خودِ حساب‌ها حذف نمی‌شوند. آن‌ها را زیر کاربران درگاه می‌بینید.

اجازهٔ تغییردادن​

ورود همان چیزی است که نوشتن را ممکن می‌کند: بازدیدکننده به‌محض اینکه برای هر کار ردیفی به چه چیزی را می‌خواند بیفزایید، می‌تواند رکورد بسازد، تغییر دهد و حذف کند. ببینید بگذارید بازدیدکنندگان تغییرات را ذخیره کنند.

مرتبط​