تاکنون با مفاهیم اولیه و برخی از جنبه های معماری HTTP آشنا شده اید. این ما را به موضوع مهم بعدی در HTTP سوق می دهد: شناسایی کلاینت.
در این مقاله، یاد خواهید گرفت که چرا شناسایی کلاینت مهم است و چگونه وب سرورها می توانند شما (Web client شما) را شناسایی کنند. همچنین می توانید نحوه استفاده و ذخیره این اطلاعات را مشاهده کنید.
این سومین قسمت از سری HTTP است.
در این مقاله با این موارد بیشتر آشنا خواهید شد:
- شناسایی کلاینت و چرا این موضوع خیلی مهم است
- شیوه های شناسایی یک کلاینت
- HTTP Request Header های مورد استفاده برای شناسایی
- آدرس IP
- URL های طولانی (Fat)
- کوکی ها
ابتدا ببینیم چرا وب سایت ها باید شما را شناسایی کنند.
شناسایی کلاینت و چرا این موضوع خیلی مهم است
همانطور که مطمئناً می دانید، هر وب سایت یا حداقل آنهایی که به اندازه کافی به شما و اقدامات شما اهمیت می دهند، شامل نوعی از شخصی سازی محتوا هستند.
منظور من از این حرف چیست؟
خب، این شامل این موارد میشود: آیتمهای پیشنهادی در صورت بازدید از وبسایت تجارت الکترونیک، یا «پیشنهاد افرادی که ممکن است بشناسید/بخواهید با آنها در شبکههای اجتماعی ارتباط برقرار کنید»، ویدیوهای توصیهشده، تبلیغاتی که تقریباً به طرز وحشتناکی نیاز شما را میدانند، مقالات خبری مرتبط با شما و غیره.
این اثر شبیه یک شمشیر دو لبه است. از یک طرف، بسیار جالب است که محتوای شخصی و سفارشی به شما تحویل داده شود. از سوی دیگر، می تواند منجر به سوگیری تاییدی شود که می تواند منجر به انواع کلیشه ها و تعصبات شود. یک کمیک عالی از دیلبرت وجود دارد که به سوگیری تاییدیه می پردازد.
با این حال، چگونه می توانیم زندگی کنیم بدون اینکه بدانیم تیم محبوب ما دیشب چگونه گل زده است یا افراد مشهور دیشب چه کاری انجام داده اند؟
در هر صورت، شخصیسازی محتوا بخشی از زندگی روزمره ما شده است که نمیتوانیم و احتمالاً حتی نمیخواهیم کاری در مورد آن انجام دهیم.
بیایید ببینیم چگونه سرورهای وب می توانند شما را برای دستیابی به این اثر شناسایی کنند.
شیوه های شناسایی یک کلاینت
چندین راه وجود دارد که یک وب سرور می تواند شما را شناسایی کند:
- HTTP request header ها
- آدرس IP
- URL های طولانی
- کوکی ها
- اطلاعات Login (احراز هویت)
یکی یکی آنها را بررسی میکنیم. احراز هویت HTTP با جزئیات بیشتر در قسمت 4 سری HTTP توضیح داده شده است.
HTTP Request Header های مورد استفاده برای شناسایی
سرورهای وب به طور مستقیم چند راه برای استخراج اطلاعات در مورد شما از HTTP Request Header ها دارند.
این header ها عبارتند از:
- From – در صورت ارائه، حاوی آدرس ایمیل کاربران است
- User-Agent – حاوی اطلاعات مربوط به سرویس گیرنده وب است
- Referer – حاوی منبعی است که کاربر از آن آمده است
- Authorization – شامل نام کاربری و رمز عبور است
- Client-IP – شامل آدرس IP کاربران است
- X-Forwarded-For – حاوی آدرس IP کاربر (هنگام عبور از سرور پروکسی)
- Cookie – حاوی برچسب شناسه تولید شده توسط سرور است
در تئوری، هدر From برای شناسایی منحصر به فرد کاربر، ایده آل است، اما در عمل، به دلیل نگرانی های امنیتی جمع آوری ایمیل، از این Header به ندرت استفاده می شود.
user-agent header حاوی اطلاعاتی مانند نسخه مرورگر و سیستم عامل است. در حالی که این برای سفارشی کردن محتوا مهم است، کاربر را به روشی مرتبطتر شناسایی نمیکند.
هدر Referer به سرور می گوید که کاربر از کجا آمده است. این اطلاعات برای بهبود درک رفتار کاربر استفاده می شود، اما کمتر برای شناسایی آن استفاده می شود.
در حالی که این header ها اطلاعات مفیدی در مورد client ارائه می دهند، برای شخصی سازی محتوا به روشی معنادار کافی نیست.
header های باقی مانده مکانیسم های دقیق تری برای شناسایی ارائه می دهند.
آدرس IP
روش شناسایی client با آدرس IP، در گذشته زمانی که آدرسهای IP به راحتی جعل/مبادله نمیشدند بیشتر مورد استفاده قرار میگرفت. اگرچه می توان از آن به عنوان یک بررسی امنیتی اضافی استفاده کرد، اما به اندازه کافی قابل اعتماد نیست که به تنهایی مورد استفاده قرار گیرد.
در اینجا به برخی از دلایل این امر اشاره می کنیم:
- آدرس IP، ماشین را توصیف می کند، نه کاربر را.
- فایروال های NAT – بسیاری از ISP ها (ارائه دهندگان خدمات اینترنتی) از فایروال های NAT برای افزایش امنیت و مقابله با کمبود آدرس IP استفاده می کنند.
- proxy های HTTP و gateway ها – اینها می توانند آدرس IP اصلی را پنهان کنند. برخی از پراکسی ها از Client-IP یا X-Forwarded-For استفاده می کنند.
URL های طولانی (Fat)
این غیر معمول نیست که ببینیم وب سایت ها از URL ها برای بهبود تجربه کاربری استفاده می کنند. آنها اطلاعات بیشتری را در حین browse کردن وب سایت توسط کاربر اضافه می کنند تا جایی که URL ها پیچیده و ناخوانا به نظر برسند.
با browse کردن فروشگاه آمازون می توانید ببینید که URL طولانی به چه شکل است.
1 |
https://www.amazon.com/gp/product/1942788002/ref=s9u_psimh_gw_i2?ie=UTF8&fpl=fresh&pd_rd_i=1942788002&pd_rd_r=70BRSEN2K19345MWASF0&pd_rd_w=KpLza&pd_rd_wg=gTIeL&pf_rd_m=ATVPDKIKX0DER&pf_rd_s=&pf_rd_r=RWRKQXA6PBHQG52JTRW2&pf_rd_t=36701&pf_rd_p=1cf9d009-399c-49e1-901a-7b8786e59436&pf_rd_i=desktop |
هنگام استفاده از این روش چندین مشکل وجود دارد.
- زشت به نظر میرسد
- قابل اشتراک گذاری نیست
- caching را خراب می کند
- محدود به فقط همان session است
- بار روی سرور را افزایش می دهد
کوکی ها
بهترین روش به روز شناسایی client بدون احراز هویت میباشد. توسط Netscape توسعه یافته است، اما اکنون هر مرورگری از آنها پشتیبانی می کند.
دو نوع کوکی وجود دارد: کوکیهای session و کوکیهای دائمی. یک کوکی session پس از خروج از مرورگر حذف میشود و کوکیهای دائمی روی دیسک ذخیره میشوند و میتوانند بیشتر دوام داشته باشند. برای اینکه کوکی session به عنوان کوکی دائمی در نظر گرفته شود، باید ویژگی Max-Age یا Expiry برای آن تنظیم شود.
مرورگرهای مدرن مانند کروم و فایرفاکس میتوانند فرآیندهای پسزمینه را هنگامی که آنها را میبندید به کار خود ادامه دهند تا بتوانید از جایی که کار را متوقف کردهاید دومرتبه از سر بگیرید. این می تواند منجر به حفظ کوکی های session شود، بنابراین مراقب باشید.
پس کوکی ها چگونه کار می کنند؟
کوکی ها حاوی لیستی از جفت های name=value هستند که سرور آنها را با استفاده از header پاسخ Set-Cookie یا Set-Cookie2 تنظیم می کند. معمولاً اطلاعات ذخیره شده در یک کوکی نوعی شناسه client است، اما برخی از وب سایت ها اطلاعات دیگری را نیز ذخیره می کنند.
مرورگر این اطلاعات را در پایگاه داده کوکی خود ذخیره می کند و زمانی که کاربر دفعه بعد از صفحه/وب سایت بازدید کرد، آن را برمی گرداند. مرورگر میتواند هزاران کوکی مختلف را مدیریت کند و میداند هر کدام را باید در چه زمانی ارائه دهد.
در اینجا یک نمونه جریان وجود دارد.
- User Agent -> Server
1 2 |
POST /acme/login HTTP/1.1 [form data] |
کاربر خود را از طریق form input شناسایی می کند.
2. Server -> User Agent
1 2 |
HTTP/1.1 200 OK Set-Cookie2: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme" |
سرور هدر پاسخ Set-Cookie2 را می فرستد تا به User Agent (مرورگر) دستور دهد تا اطلاعات کاربر را در یک کوکی تنظیم کند.
3. User Agent -> Server
1 2 3 |
POST /acme/pickitem HTTP/1.1 Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme" [form data] |
کاربر کالای مورد نظر را در سبد خرید انتخاب می کند.
4. Server -> User Agent
1 2 |
HTTP/1.1 200 OK Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1"; Path="/acme" |
سبد خرید حاوی یک کالا است.
5. User Agent -> Server
1 2 3 4 |
POST /acme/shipping HTTP/1.1 Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"; Part_Number="Rocket_Launcher_0001"; [form data] |
کاربر روش ارسال را انتخاب می کند.
6. Server -> User Agent
1 2 |
HTTP/1.1 200 OK Set-Cookie2: Shipping="FedEx"; Version="1"; Path="/acme" |
کوکی جدید، روش حمل و نقل را منعکس می کند.
7. User Agent -> Server
1 2 3 4 5 6 |
POST /acme/process HTTP/1.1 Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"; Part_Number="Rocket_Launcher_0001"; $Path="/acme"; Shipping="FedEx"; $Path="/acme" [form data] |
تمام.
یک چیز دیگر وجود دارد که می خواهم از آن آگاه باشید. کوکی ها هم بی نقص نیستند. علاوه بر نگرانیهای امنیتی، مشکلی در برخورد کوکیها با سبک معماری REST نیز وجود دارد. (بخش استفاده نادرست از کوکی ها).
می توانید در مورد کوکی ها در RFC 2965 اطلاعات بیشتری کسب کنید.
نتیجه گیری
شما نقاط قوت شخصی سازی محتوا و همچنین مشکلات احتمالی آن را یاد گرفته اید. شما همچنین از راه های مختلفی که سرورها می توانند برای شناسایی شما استفاده کنند آگاه هستید. در قسمت 4 این مجموعه، در مورد مهمترین نوع شناسایی کلاینت صحبت خواهیم کرد: احراز هویت.
اگر برخی از مفاهیم این قسمت را نامفهوم دیدید، به قسمت 1 و قسمت 2 سری HTTP مراجعه کنید.