3 کاربر معتبر

کاربران R بدون در نظر گرفتن روش احراز هویت RSTUDIO که از آنها استفاده می کنید ، به حساب های سیستم محلی نیاز دارند. شما باید حساب های سیستم محلی را به صورت دستی تنظیم کنید و سپس تأیید اعتبار کاربران را به این حساب ها تنظیم کنید. همچنین می توانید از PAM Sessions برای نصب دایرکتوری خانه کاربر خود به سرور استفاده کنید.

توجه: همه محصولات RSTUDIO به حساب سیستم محلی احتیاج ندارند. سرور براق و RSTUDIO Coect به کاربران نهایی خدمت می کنند ، نه توسعه دهندگان R ، بنابراین این محصولات بدون حساب های سیستم محلی می توانند پیکربندی شوند.

3. 1 احراز هویت PAM

سرور RSTUDIO کاربران را از طریق API استاندارد Linux Standard PAM (ماژول احراز هویت قابل استفاده) تأیید می کند. PAM به طور پیش فرض برای تأیید اعتبار در برابر پایگاه داده کاربر سیستم ( /etc /passwd) پیکربندی می شود ، اما می تواند برای تأیید اعتبار در برابر طیف گسترده ای از سیستم های دیگر از جمله Activedirectory و LDAP پیکربندی شود.

در این بخش پیکربندی PAM مورد استفاده برای تأیید اعتبار به طور پیش فرض پس از نصب توصیف شده است. توجه داشته باشید که PAM می تواند برای تأیید اعتبار و همچنین برای تنظیم محیط برای جلسات کاربر (جلسات PAM) استفاده شود. در این بخش فقط احراز هویت توضیح داده شده است ، برای جزئیات بیشتر در مورد چگونگی پیکربندی سرور RSTUDIO برای استفاده از جلسات PAM ، به بخش [منابع کاربر و محدودیت ها] مراجعه کنید.

3. 1. 1 اصول اولیه PAM

پروفایل های PAM در فهرست /etc/pam. d قرار دارند. هر برنامه می تواند مشخصات خاص خود را داشته باشد ، و همچنین یک پروفایل پیش فرض برای برنامه های بدون آن استفاده می شود (مشخصات پیش فرض بسته به اینکه نسخه لینوکس را اجرا می کنید متفاوت است).

برای کسب اطلاعات بیشتر در مورد PAM و بسیاری از گزینه ها و ماژول های موجود برای آن موارد زیر را مشاهده کنید:

• http://en. wikipedia. org/wiki/pluggable_authentication_module
• http://www. centos. org/docs/5/html/deployment_guide-en-us/ch-pam. html
• http://tldp. org/howto/user-authentication-howto/x115. html
• http://linux. die. net/man/8/pam

3. 1. 2 پیکربندی پیش فرض PAM

دبیان / اوبونتو

در سیستم های Debian و Ubuntu Rstudio Server یک فایل پیکربندی PAM خاص RSTUDIO ارائه نمی دهد. در نتیجه ، سرور RStudio از پروفایل /etc/pam. d/other استفاده می کند ، که به طور پیش فرض از مجموعه ای از پرونده های پیکربندی مشترک به ارث می برد:

 @عبارتند ازuth common-uth include common-account include common-password includ

اگر پروفایل/etc/pam. d/ other منعکس کننده سیستم احراز هویت و خط مشی هایی است که دوست دارید سرور RStudio از آن استفاده کند ، پس از آن پیکربندی دیگری لازم نیست. اگر می خواهید یک پروفایل PAM سفارشی برای RSTUDIO ایجاد کنید ، پرونده ای به نام /etc/pam. d/rstudio ایجاد می کنید و هر تنظیمات مناسب را مشخص می کنید.

redhat / centos / suse

در مورد برنامه های Redhat ، Centos و Suse Systems بدون پروفایل PAM خود به طور پیش فرض از دسترسی محروم می شوند. بنابراین برای اطمینان از نصب RSTUDIO در حال اجرا و در دسترس است ، مشخصات پیش فرض PAM در /etc/pam. d/rstudio نصب شده است. این پروفایل پیکربندی شده است تا به یک کاربر کاربر بیشتر از 500 نیاز داشته باشد و کاربران را در برابر حساب های سیستم محلی تأیید کند:

زبانمورد نیاز PAM_SUCVEST_IF. SO UID>= 500 آرامزبانمورد نیاز pam_unix. so nodelayحسابمورد نیاز Pam_unix. so

این پروفایل پیش فرض PAM ممکن است منعکس کننده رفتار احراز هویت مورد نظر شما برای سرور RSTUDIO نباشد. در این حالت ، ممکن است برخی از سفارشی سازی ها مورد نیاز باشد. اگر قبلاً مشخصات PAM دیگری (به عنوان مثال /etc/pam. d/login) را با رفتار مورد نظر تنظیم کرده اید ، ممکن است کافی باشد که به سادگی آن نمایه را از طریق RSTUDIO کپی کنید. مثلا:

$ سوداcp /etc/pam. d/login /etc/pam. d/rstudio

3. 1. 3 تشخیص مشکلات احراز هویت PAM

اگر قادر به ورود به سرور RSTUDIO نیستید ممکن است یک مشکل اساسی در پیکربندی PAM ایجاد شود. بهترین راه برای تشخیص مشکلات پیکربندی PAM استفاده از ابزار Pamtester (که با سرور RSTUDIO همراه است) است. استفاده از Pamtester شما را قادر می سازد تا تأیید هویت را در یک محیط جدا شده و همچنین مشاهده های بسیار دقیق تر آزمایش کنید.

ابزار Pamtester در/usr/lib/rstudio-server/bin/pamtester قرار دارد. برای استناد به آن ، چندین آرگومان را نشان می دهید که نمایه PAM را برای تست ، کاربر برای آزمایش و اینکه آیا می خواهید خروجی کلامی باشد ، تصویب می کنید. مثلا:

سودا/usr/lib/rstudio-server/bin/pamtester-verbose rstudioنام کاربری>تصدیق کردن

می توانید مستندات دقیق تری در مورد استفاده از Pamtester در اینجا بیابید: http://linux. die. net/man/1/pamtester.

3. 1. 4 مدیریت طول عمر ورود به سیستم

هنگام ورود به سیستم با استفاده از تأیید اعتبار PAM گزینه ای برای امضای در جلسات مرورگر دارند. به طور پیش فرض هنگام انتخاب اقامت در امضای کاربران گزینه ، به مدت 30 روز وارد سیستم می شوند. شما می توانید این رفتار را با استفاده از تنظیمات Auth-Signed-in-Days اصلاح کنید. مثلا:

AUTH-SING-SINGED-در روز=7

شما می توانید با استفاده از تنظیمات امضا شده Auth-Wide-Signed ، این گزینه را به طور کامل از نمایش این گزینه جلوگیری کنید. مثلا:

امضای AUTH-SING=0

تنظیم این گزینه در 0 باعث می شود که کاربران از آنها بخواهند هر بار که یک جلسه مرورگر جدید را شروع می کنند وارد سیستم شوند (یعنی ورود به سیستم فقط تا زمانی که فرآیند مرورگر که در آن سرچشمه می گیرند ، معتبر خواهد بود).

3. 2 محدود کردن دسترسی به کاربران خاص

3. 2. 1 حداقل شناسه کاربر

به طور پیش فرض سرور RSTUDIO فقط به کاربران عادی (بر خلاف سیستم) اجازه می دهد تا با موفقیت تأیید کنند. حداقل شناسه کاربر با خواندن مقدار uid_min از پرونده /etc/login. defs تعیین می شود. اگر پرونده وجود نداشته باشد یا uid_min در آن تعریف نشده باشد ، از مقدار پیش فرض 1000 استفاده می شود.

شما با مشخص کردن گزینه Auth-Minimum-User-ID حداقل شناسه کاربر را تغییر می دهید. مثلا:

AUTH-MINIMUM-USER-ID=100

توجه داشته باشید که این امکان وجود دارد که پیکربندی PAM شما نیز از محدودیت در ID های کاربر استفاده کند (برای مثال به بخش پیش فرض پیکربندی PAM در بالا مراجعه کنید). در این حالت باید اطمینان حاصل کنید که Auth-Minimum-User-ID با مقدار مشخص شده در پیکربندی PAM شما سازگار است.

اگر کاربران شما از UID های بسیار بزرگ استفاده می کنند (بالاتر از 1048575/0xFFFFF) ، به شدت توصیه می شود مقدار Auth-Minimum-user-id را تنظیم کنید تا RSTUDIO را فعال کنید تا هنگام نقشه برداری از شناسه های کاربر به پروژه ها فرضیات بهتری داشته باشد.

3. 2. 2 محدود کردن توسط گروه

می توانید مشخص کنید که فقط کاربران گروههای خاص مجاز به دسترسی به سرور RSTUDIO هستند. برای این کار شما از تنظیمات گروهی Auth-Required-User-Group استفاده می کنید. مثلا:

گروه سازگار=کاربران رزمنده

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

گروه سازگار=تحلیلگران ، سرپرستان ، کاربران RSTUDIO

توجه داشته باشید که تا زمان شروع مجدد سرور ، این تغییر عملی نخواهد شد.

3. 2. 2. 1 ایجاد و مدیریت عضویت در گروه

برای ایجاد یک گروه جدید از دستور GroupAdd استفاده می کنید:

$ سوداگروهاسم گروه>

برای افزودن کاربر به یک گروه موجود ، از دستور usermod استفاده می کنید:

$ سوداusermo d-a -gاسم گروه> نام کاربری>

توجه داشته باشید که بسیار مهم است که شما پرچ م-a را درج کنید زیرا این نشان می دهد که این گروه باید به جای جایگزینی لیست گروه کاربر در کل ، به کاربر اضافه شود.

3. 3 حساب Google

سرور RSTUDIO را می توان برای تأیید اعتبار کاربران از طریق حساب های Google پیکربندی کرد. این کار کاربران را قادر می سازد تا با اعتبار GMAIL یا Google Apps موجود خود وارد سیستم شوند و هر زمان که قبلاً وارد حساب Google خود شوند ، به طور خودکار به سرور RStudio تأیید می شوند.

3. 3. 1 ثبت نام در Google

به منظور استفاده از حساب های Google با سرور RSTUDIO ، باید سرور خود را در Google برای تأیید اعتبار OAUTH 2. 0 ثبت کنید. شما این کار را با ایجاد "پروژه" جدید برای سرور خود در کنسول Google Developer انجام می دهید:

پس از ایجاد یک پروژه ، به حوزه اعتبار API ها و Auth می روید و برای ایجاد شناسه مشتری جدید تصمیم می گیرید:

شناسه مشتری را ایجاد کنید

سپس گفتگوی مورد استفاده برای ایجاد شناسه مشتری جدید ارائه می شود:

شناسه مشتری را ایجاد کنید

شما باید "برنامه وب" را به عنوان نوع برنامه انتخاب کنید و دو URL ارائه دهید که مطابق با سرور مورد نظر شما است. تصویر بالا از https://www. example. com به عنوان میزبان استفاده می کند ، باید دامنه و پورت خود را (در صورت عدم استفاده از استاندارد مانند 80 یا 443) در پیکربندی خود جایگزین کنید.

این منجر به دو مقدار می شود که شما باید به عنوان بخشی از پیکربندی سرور RSTUDIO ارائه دهید: مشتری-ID و مشتری مخفی (آنها پس از اتمام گفتگو در کنسول Google Developer نمایش داده می شوند).

3. 3. 2 فعال کردن حساب های Google

برای فعال کردن احراز هویت با حساب های Google ، گزینه Auth-Google-Accounts را به پرونده پیکربندی سرور RSTUDIO اضافه می کنید:

دارای حسابهای گوگل=1

علاوه بر این ، شما باید یک پرونده پیکربندی (/etc/rstudio/google-clent-secret) حاوی مشتری-ID و مشتری مخفی را که هنگام ثبت سایت خود با Google دریافت کرده اید ، اضافه کنید. به عنوان مثال ، پرونده پیکربندی ممکن است به این شکل باشد:

شناسه مشتری=llllllllllllll-xxxxxxxxxxxxxxxxxxxxx. apps. googleusercontent. com مخفی مشتری=bhcc6rk7sj2ztph0ord7lo1w

پرونده/etc/rstudio/google-clent-secret باید مجوزهای پرونده را بخواند/بنویسد (یعنی 0600) برای محافظت از محتویات آن از سایر کاربران. می توانید این را به شرح زیر اطمینان حاصل کنید:

$ سوداchmod 0600/etc/rstudio/google-clent-secret

توجه داشته باشید که Client-ID و Client-Sector فوق مقادیر واقعی مورد استفاده شما نیستند. در عوض ، شما باید مقادیری را که از Google به دست آورده اید هنگام ثبت سایت خود برای احراز هویت OAuth جایگزین کنید.

هنگامی که شما می توانید احراز هویت را با حساب های Google که به وسیله انحصاری احراز هویت تبدیل می شود ، فعال کنید (شما نمی توانید همزمان از تأیید اعتبار حساب PAM و Google استفاده کنید).

3. 3. 3 ترجمه به حساب های محلی

3. 3. 3. 1 ایجاد حساب های تطبیق

هنگامی که کاربر از طریق حساب های Google تأیید شد ، لازم است هویت حساب های Google خود را به یک حساب سیستم محلی نقشه برداری کنید. پیش فرض و ساده ترین روش برای انجام این کار ، ایجاد یک حساب محلی با نام کاربری یکسان با آدرس ایمیل Google آنها است.

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

یک مشکل در ایجاد حساب های محلی که با آدرس ایمیل Google مطابقت دارند این است که آنها اغلب شامل کاراکترهایی هستند که به طور پیش فرض در نام های کاربری لینوکس نامعتبر هستند (به عنوان مثال @ یا.). در سیستم های Debian/Ubuntu می توان سیستم را مجبور به ایجاد کاربر با این شخصیت ها کرد. در اینجا نمونه ای از ایجاد یک کاربر با نام کاربری وجود دارد که شامل شخصیت های معمولاً نامعتبر است:

$ سوداaddUser-Force-badnameنام کاربری>

توجه داشته باشید که گزینه-force-badname فقط در سیستم های Debian/Ubuntu در دسترس است و در سیستم های REDHAT/CentOS یا SLES در دسترس نیست.

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

$ سوداAddUser--force-badname--تشخیص داده شده-login--تشخیص داده شدهنام کاربری>

3. 3. 3. 2 با استفاده از پرونده نگاشت حساب

از طرف دیگر ، شما نقشه های محلی ایجاد می کنید که با آدرس های ایمیل Google مطابقت ندارند و سپس نقشه برداری از حساب های Google را به حساب های محلی از طریق پرونده پیکربندی/etc/rstudio/google-accounts مشخص می کنید. مثلا:

john. smith@gmail. com=jsmith sally. jones@gmail. com=گنگ

توجه داشته باشید که تغییر در پرونده پیکربندی حساب های Google بلافاصله عملی می شود و نیازی به راه اندازی مجدد سرور ندارد.

3. 3. 4 ملاحظات پروکسی

اگر RSTUDIO را در پشت پروکسی اجرا می کنید ، باید پروکسی خود را پیکربندی کنید تا نام میزبان آن را در عنوان X-Forwarded-Host تنظیم کنید تا RSTUDIO بتواند به خدمات وب Google بگوید تا به مکان صحیح تغییر مسیر دهد. به عنوان مثال ، اگر پروکسی شما برای ارائه درخواست های RSTUDIO در http://testdomain. com/rstudio/ تنظیم شده است ، می خواهید اطمینان حاصل کنید که پروکسی عنوان X-forwarded-host را به http://testdomain. com/ تنظیم کرده است. RSTUDIO/. در غیر این صورت ، Rstudio سعی خواهد کرد تا به آدرس داخلی خود برگردد.

از طرف دیگر ، اگر شما در پشت یک پروکسی در حال اجرا هستید اما به هر دلیلی نمی توانید عنوان X-forwarded-Host را تنظیم کنید ، می توانید از گزینه Auth-Google-Accounts-Redirect-Base-URI استفاده کنید تا در پرونده پیکربندی سرور RSTUDIO یکسان باشد. هدف:

auth-google-accounts-redirect-base-uri=http://testdomain. com/rstudio/

3. 4 سفارشی کردن صفحه ورود به سیستم

می توانید با استفاده از HTML سفارشی در صفحه ، محتوا و ظاهر صفحه ورود به سیستم RSTUDIO را سفارشی کنید. این توسط هر دو انجام می شود:

1. تهیه پرونده در /etc/rstudio/login. html که شامل HTML اضافی است تا در صفحه ورود به سیستم گنجانده شود. یا
2. مشخص کردن گزینه auth-login-page-html در پرونده پیکربندی rserver. conf که به یک مکان متناوب برای پرونده html ورود اشاره می کند. به عنوان مثال ، موارد زیر مشخص می کند که پرونده واقع در /opt/config/rstudio-login. html باید در صفحه ورود به سیستم گنجانده شود: /etc/rstudio/rserver. conf

    

auth-login-page-html=/opt/config/rstudio-login. html

محتوای پرونده HTML مشخص شده پس از هدر ورود استاندارد و فرم نام کاربری/رمز ورود وارد می شود. اگر می خواهید ظاهر هدر را تغییر دهید و/یا محتوا را در بالای فرم نام کاربری/رمز عبور اضافه کنید ، می توانید از CSS و JavaScript در پرونده login. html خود استفاده کنید تا صفحه را پس از بارگیری تغییر دهید.

احراز هویت پروکسی 3. 5

شما می توانید سرور RSTUDIO را برای شرکت در یک طرح احراز هویت تک علامت مبتنی بر وب موجود با استفاده از احراز هویت پروکسی پیکربندی کنید. در این پیکربندی ، تمام ترافیک به سرور RSTUDIO توسط یک سرور پروکسی انجام می شود که همچنین تأیید اعتبار کاربر را انجام می دهد.

در این پیکربندی ، سرور پروکسی یک عنوان HTTP ویژه را به درخواست سرور RSTUDIO اضافه می کند و به آن می داند که کاربر معتبر درخواست را ایجاد می کند. سرور RSTUDIO به این هدر اعتماد دارد و ترافیک را به یک جلسه R متعلق به کاربر مشخص شده راه اندازی و هدایت می کند.

کاربر مشخص شده باید یک حساب سیستم محلی در سرور داشته باشد. شما باید حساب های سیستم محلی را به صورت دستی تنظیم کنید و سپس تأیید اعتبار کاربران را به این حساب ها تنظیم کنید.

3. 5. 1 فعال کردن احراز هویت پروکسی

برای فعال کردن احراز هویت پروکسی ، باید تنظیمات Auth-Proxy و Auth-Proxy-Sign-In-URL را مشخص کنید (URL ورود به سیستم URL مطلق به صفحه ای است که کاربران باید برای ورود به سیستم هدایت شوند). مثلا:

عبوس=1 عتیق=http://example. com/sign-in

توجه داشته باشید که تا زمان شروع مجدد سرور ، تغییرات در پیکربندی عملی نمی شود.

3. 5. 2 اجرای پروکسی

3. 5. 2. 1 وارد URL

نشانه در URL باید میزبان صفحه ای باشد که کاربر اعتبار خود را مشخص کند (این ممکن است به عنوان مثال صفحه اصلی برای یک سیستم احراز هویت مبتنی بر وب باشد). پس از جمع آوری و مجوز اعتبار ، علامت URL باید به URL میزبان سرور RSTUDIO برگردانده شود.

Rstudio تحت شرایط زیر به علامت URL هدایت می شود:

1. هر زمان که درخواست HTTP که فاقد عنوان نام کاربری است ، توسط سرور دریافت می شود. وت
2. هنگامی که کاربر روی دکمه "ورود به سیستم" در رابط کاربری RSTUDIO IDE کلیک کرد.

شما باید در تنظیم سرور پروکسی مطمئن باشید که ترافیک محدود به URL ورود به سیستم از ارسال به سرور RSTUDIO مستثنی است (در غیر این صورت در یک حلقه تغییر مسیر بی نهایت به پایان می رسد).

3. 5. 2. 2 ارسال نام کاربری

هنگام پخش ترافیک از قبل معتبر به سرور RSTUDIO ، باید یک عنوان HTTP ویژه (به طور پیش فرض نام X-RSTUDIO-USERNANG) را درج کنید و هر درخواست نشان می دهد که درخواست کاربر با کدام کاربر همراه است. مثلا:

نام X-Rstudio-Useame: Jsmith

همچنین می توان نام کاربری سیستم و نام کاربری نمایشگر را مشخص کرد (در موردی که حساب های سیستم به صورت پویا تهیه شده و هویت واقعی کاربر را منتقل نمی کنند). مثلا:

نام X-RSTUDIO-USERNAME: RSUSER24/JSMITH

توجه داشته باشید که بسیار توصیه می شود که از نام هدر پیش فرض X-RSTUDIO-USERINAME استفاده نکنید. دلایل این امر بلافاصله در بخش ملاحظات امنیتی شرح داده شده است.

3. 5. 2. 3 بازنویسی نام های کاربری

ممکن است که سیستم پروکسی که شما استفاده می کنید نام کاربری را در فرمی ارسال می کند که با کاربران روی سیستم مطابقت ندارد ، اما می تواند به راحتی به شخصی تبدیل شود (به عنوان مثال پیشوند استاندارد قبل از نام کاربری). در این صورت می توانید گزینه Auth-proxy-user-header-retrite را مشخص کنید تا یک قانون نوشتن مجدد برای هدر ورودی ارائه دهید. به عنوان مثال ، قانون زیر پیشوند "uid-" را از یک نام کاربری باز می کند:

auth-proxy-user-header-rewrite =^uid-([a-z]+) $ 1 $

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

3. 5. 3 ملاحظات امنیتی

3. 5. 3. 1 نگه داشتن نام هدر را مخفی نگه دارید

با استفاده از نام پیش فرض نام X-RSTUDIO-USERNAME یک مشکل امنیتی ایجاد می کند: کدی که در پشت پروکسی (یعنی کد در جلسات R) اجرا می شود می تواند درخواست هایی را به سرور برگرداند که از سایر کاربران استفاده می کند (با قرار دادن هدر در درخواست آنها).

برای جلوگیری از این مسئله می توانید نام هدر سفارشی را که از کاربران نهایی مخفی نگه داشته می شود ، مشخص کنید. این کار با ایجاد یک فایل پیکربندی ویژه (/etc/rstudio/secure-proxy-user-header) انجام می شود که حاوی نام هدر است ، و سپس تنظیم مجوزهای پرونده آن را به گونه ای تنظیم می کند که توسط کاربران عادی قابل خواندن نباشد. مثلا:

سوداs h-c"echo 'X-Secret-User-Header'>/و غیره/rstudio/Secure-Proxy-User-Header " سوداchmod 0600/etc/rstudio/secure-proxy-user-header

3. 5. 3. 2 جلوگیری از استفاده از راه دور از هدر

هنگام اجرای پروکسی مهم است که به یاد داشته باشید که سرور RSTUDIO همیشه به عنوان کاربری برای تأیید اعتبار کاربران اعتماد خواهد کرد. بنابراین از نظر امنیت بسیار مهم است که تمام درخواست های منشأ حاصل از پروکسی ، این هدر را صریحاً توسط پروکسی تنظیم کرده اند (بر خلاف اجازه دادن به هدر توسط یک مشتری از راه دور مشخص می شود).

3. 5. 3. 3 امضاهای HMAC پروکسی

شما می توانید RSTUDIO را مجبور به تأیید امضای HMAC در درخواست ها علاوه بر عنوان مخفی کنید ، و بیشتر امنیت سیستم خود را تضمین کنید. نیاز به تأیید امضاهای درخواست ، RSTUDIO را وادار می کند تا فقط درخواست های معتبر از طرف پروکسی را مجاز می دانند.

برای نیاز به امضاهای HMAC ، موارد زیر را به فایل پیکربندی خود /etc/rstudio/rserver. conf اضافه کنید:

auth-proxy-require-hmac=1

این امر به RSTUDIO نیاز دارد تا اطمینان حاصل شود که کلیه درخواست های دریافتی حاوی امضای معتبر HMAC در هدر امضای X-Proxy است. برای امضای صحیح درخواست ها ، پروکسی شما باید HMAC SHA-256 از قسمت های انتخابی درخواست را با استفاده از کلید Secure Cookie Rstudio محاسبه کرده و نتیجه را در عنوان X-Proxy-Signature ذخیره کند. برای اطلاعات بیشتر در مورد کلید Secure Cookie ، به بخش تعادل بار مراجعه کنید.

علاوه بر این ، شما باید عنوان تاریخ را در درخواست ها مشخص کنید ، که باید طبق استاندارد HTTP فرمت شود (مثال: چهارشنبه ، 21 اکتبر 2017 07:28:00 GMT). تاریخ های مناسب همیشه از منطقه زمانی GMT استفاده می کنند.

رشته ای که باید امضا شود باید مانند موارد زیر ساخته شود:

X-پروکسی-امضا =sha_256(نام کاربری+ "
" +هدر تاریخ+ "
" +بدنه درخواست) 

به عنوان مثال ، فرض کنید که ما پیام زیر را در ساعت 11:50 صبح روز سه شنبه 5 سپتامبر در منطقه زمانی CDT (-5: 00) در حال پخش بودیم و ما تعیین کردیم که این درخواست از BDYLAN کاربر آمده است:

گرفتن/HTTP/1.1کاربر-عامل:موزیلا/4.0(سازگار ؛ msie5. 01؛ویندوز NT) میزبان:مرکز محلی:8787تایید کنید-زبان:در-ما قبول می کنیم-رمز:GZIP ، اتصال را خنثی کنید:نگاه داشتن-زنده این یک بدن نمونه است!

امضای ساخته شده به این شکل است:

X-پروکسی-امضا =sha_256("Bdylan
سه شنبه ، 05 سپتامبر 2017 16:50:00 GMT
این یک بدن نمونه است! "، secure_cookie_key) x-پروکسی-امضا = 01D90C8F2CE7DE3FB75BF183FE50630CC737E2E1129BA18EA6276231E46313

توجه داشته باشید که امضای SHA_256 فوق صرفاً نمونه ای است. این برای هر SEFER_COOKIE_KEY ممکن است متفاوت باشد.

3. 5. 4 عیب یابی با سیاهههای مربوطه

اگر می خواهید دقیقاً ببینید که سرور RSTUDIO در حال دریافت است و آیا آنها اطلاعات نام مورد انتظار را شامل می شوند ، می توانید با استفاده از تنظیمات دسترسی به سرور-دسترسی به صورت زیر ، گزارش های دسترسی به سرور را به طور موقت فعال کنید:

/etc/rstudio/rserver. conf

دارای دسترسی سرور=1

پس از راه اندازی مجدد سرور RSTUDIO ، پرونده زیر حاوی سابقه ای از هر درخواست HTTP است که به سرور همراه با کد پاسخ HTTP است:

/var/log/rstudio-server/rserver-http-access. log

پرونده ورود به سیستم شامل ورودی هایی خواهد بود که به این شکل است:

127. 0. 0. 1 - - [29/ژوئن/2015: 06: 30: 4 1-0400] "get/s/f01ddf8222bea98a/http/1. 1" 200 91 "http: // localhost: 8787/s/f01ddf8222222222222222222222222222222222222222222222222222222222222222222222222222وری5. 0 (X11 ؛ Linux x86_64) AppleWebKit/537. 36 (KHTML ، مانند Gecko) Chrome/43. 0. 2357. 125 Safari/537. 36 "" Jsmith "

توجه داشته باشید که آخرین مورد در ورود به پرونده ورود به سیستم "Jsmith" است. این نام کاربری است که سرور RStudio از عنوان منتقل شده توسط سرور پروکسی خوانده است. اگر این به صورت خالی ("-") نشان داده شود ، سرور پروکسی شما هدر را ارسال نمی کند یا از نام هدر صحیح در ارسال استفاده نمی کند.

نکته مهم: پس از نتیجه گیری عیب یابی ، مهم است که گزینه سرور-ACCESS-LOG = 1 را از پرونده /etc/rstudio/rserver. conf حذف کنید (از آنجا که این پرونده ورود به سیستم چرخانده نشده است ، در نهایت مقدار زیادی مصرف می کنداگر گزینه را حذف نکنید) فضای دیسک.