با سلام
من می خوام با curl بیام به یه سایت لوگین کنم و بعد به صفحه دیگه برم
مرحله لوگین درست انجام می شه
من کوکی هایی که می خواد داخل لوگین انجام بشه رو می گیرم و به صفحه بعد می فرستم ولی باز داخل صفحه دوم می خواد که redirect کنه
سلام،
تا جایی که می دونم بلاگفا بر اساس net. ساخته شده. توی net. حساسیت روی session های خیلی بیشتر از سایر تکنولوژی های وب هست و فقط با پاس کردن SessionID نمی شه یه session رو شبیه سازی کرد. علاوه بر SessionID یه سری پارامترهای دیگه (مثل یه سری تاریخ، یه سری عدد و ارقام و...) هم دوباره باید به صفحه .net پاس بشه تا بتونی session رو شبیه سازی کنی. دو تا راه حل وجود داره :
1- اگه بتونی برنامه رو با .net بنویسی کار خیلی راحت می شه. چون .net خودش یه object داره که تمامی کارهای مربوط به header های دریافت شده رو خود به خود handle می کنه (اسمش CookieContainer هست). یعنی فقط کافیه که header های دریافت شده رو بریزی توی این object و توی request بعدی دوباره پاسش کنی. وگرنه مجبوری خودت تمامی header های رو مو به مو تجزیه و parse کنی. (یادمه یه بار داشتم این کارو توی دلفی انجام می دادم. واقعا یه کاووس بود.)
2- راه حل دوم که بیشتر منطقیه اینه که از به برنامه TCP/IP Monitoring (که اصطلاحا بهشون می گن Sniffer) استفاده کنی. و با استفاده از اون ببینی که چه header هایی توی packet هایی که بین برنامه تو و صفحه بلاگفا ردوبدول می شه. و اون header ها رو مثلا با header هایی که اینترنت اکسپلور ردو بدول می کنه مقایسه کنی و ببینی مشکل کار کجاست. برنامه های sniffer مجانی زیادی روی اینترنت وجود داردن که یکی از اونها رو اگه نداری بگیر.
تا جایی که می دونم بلاگفا بر اساس net. ساخته شده. توی net. حساسیت روی session های خیلی بیشتر از سایر تکنولوژی های وب هست و فقط با پاس کردن SessionID نمی شه یه session رو شبیه سازی کرد. علاوه بر SessionID یه سری پارامترهای دیگه (مثل یه سری تاریخ، یه سری عدد و ارقام و...) هم دوباره باید به صفحه .net پاس بشه تا بتونی session رو شبیه سازی کنی.
زیاد این حرفت مفهومی نداره... سشن حداقل و حداکثر می تونه از کوکی استفاده کنه!! مابقی موارد.... به فرض هم که چیزی باشه، تاریخ، کلاینت یا هر چیز دیگه ای توسط مرورگر یا احیانا درخواست شما یا ... توسط curl مدیریت میشه و مشکلی باهاش نیست.
اگه ما فقط session و نوع کارکردن اون رو به صورت کلاسیک در نظر بگیریم، حرف شما درسته. اما با ترکیب SessionID که با یه سری header های دیگه می شه این مفهوم که شما بهش اشاره کردین رو تغییر داد. مثال:
-من به عنوان یک browser و یا روبوت جستجو کننده به یک سایت درخواست می دم و به همراه درخواست خودم نام کاربری و رمز عبور رو هم پاس می کنم.
-سایت مورد نظر به من جواب مثبت برای ورود می ده و یک Session ID بر می گردونه. فرض کنیم علاوه بر SessionID یه header هم برگردونده بشه که مثلا بگه test=OK
حالا اگه سایت مورد نظر فقط Session ID رو چک بکنه طبق حرف شما مشکلی پیش نمیاد. و من به عنوان یک روبوت فقط و فقط با پاس کردن Session ID و Cookie مربوطه می تونم به کارم ادامه بده.
اما اگه سایت ترکیب Session ID و مثلا هدر test رو چک بکنه جریان کاری تغییر می کنه و من مجبورم علاوه بر Session ID هدر test با مقدار OK رو هم در درخواست های بعدیم پاس بکنم.
Browser ها تمامی هدر هایی رو که نمی شناسن رو دوباره در درخواست های بعدی به سرور به صورت خودکار پاس می کنن. اونهایی رو هم که می شناسن خوب طبیعتا پردازش می کنن و مقدار مناسبش رو به سرور بر میگردونن. و بنابراین استفاده از روش دوم(ترکیت سایر هدر ها علاوه بر session id) بدون مشکل امکان پذیره.
در net. هم شنیده بودم که شناسایی session ها با استفاده از ترکیت همین هدر ها و نه فقط session id انجام می شه. اما متاسفانه هنوز مقاله و یا منبع معتبری که حرفم رو ثابت بکنه پیدا نکردم.
در مورد curl هم چون تاحالا باهاش کار نکردم نمی دونم که این کار رو خودش به صورت خودکار انجام می ده و یا نه. اما فکر نمی کنم که انجام بده. چون معمولا object های سطح پایین کارهای پایه رو انجام می دن و بقیه کارها با استفاده از سطح پایین ترین شی اون کار باید انجام بشه.
توی net هم همین طور هست و شی شبیه curl در اونجا فقط کارهای پایه رو انجام می شده و برای گرفتن کار بیشتر از اون object باید به object های دیگه و ترکیبش با شی شبیه curl متوسل شد.
اونوقت این header کجا ذخیره میشه؟؟؟
سایت **نمی تونه** و **حق** نداره چیزی جز کوکی رو چک کنه. در حقیقت این مرورگر است که کوکی رو دوباره ارسال می کنه به سمت سرور و سرور چیزی از روی کلاینت نمی خونه.
Browser ها تمامی هدر هایی رو که نمی شناسن رو دوباره در درخواست های بعدی به سرور به صورت خودکار پاس می کنن. اونهایی رو هم که می شناسن خوب طبیعتا پردازش می کنن و مقدار مناسبش رو به سرور بر میگردونن. و بنابراین استفاده از روش دوم(ترکیت سایر هدر ها علاوه بر session id) بدون مشکل امکان پذیره.
هدر لازم نیست جایی ذخیره بشه! همون طور که بقیه هدرهایی که بین سرور و کلاینت ردوبدل می شن ذخیره نمی شن (مگه در موارد خاصی که سرور یا کلاینت تصمیم به ذخیره کردن یه هدر خاص بگیره، که مصداقش هموم کوکی هست که کلاینت تصمیم می گیره از بین چندین هدر دریافت شده از یه سایت، اطلاعات موجود در هدر کوکی رو به عنوان یه کوکی ذخیره کنه). به عنوان مثال این لیست تعدادی از هدرهایی هست که شما وقتی صفحه اول گوگل رو می بینید به سرور ارسال می شه:
GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
این هم تعداد از هدرهایی هست که گوگل به کلاینت برمیگردونه:
HTTP/1.1 200 OK
Connection: Keep-Alive
Cache-Control: private
Content-Type: text/html
Content-Encoding: gzip
Server: GWS/2.1
Content-Length: 2027
Date: Thu, 12 Oct 2006 07:57:45 GMT
آیا این هدرهای ذخیره می شن؟ نه. اینها فقط برای اطلاع دادن به سری چیزها به طرف مقابل هست. البته ممکنه یکی دوتاشون هم ذخیره بشن. اما اگه ذخیره هم نشن مشکلی پیش نمیاد.
سایت **نمی تونه** و **حق** نداره چیزی جز کوکی رو چک کنه. در حقیقت این مرورگر است که کوکی رو دوباره ارسال می کنه به سمت سرور و سرور چیزی از روی کلاینت نمی خونه.
به عنوان مثال وقتی که یه سایت از روی همین هدرهایی که از طرف کلاینت به سرور پاس شده نوع Browser رو تشخیص می ده ( و یا حتی نوع سیستم عامل کلاینت و ...) آیا داره چیزی از کلاینت می خونه؟ مسلما نه. اینها اطلاعاتی هستن که به دلخواه خود کلاینت به سرور فرستاده شده. شاید اگه جلمه "سایت نمی تونه و حق نداره چیزی جز کوکی رو بخونه" رو به جمله "سایت نمی تونه و حق نداره چیزی جز هدر ها رو چک کنه." تغییر بدیم بهتر باشه. چون کوکی هم جزو کل بزرگتری به اسم هدر است و درون هدر های قرار می گیره.
در قسمت "4.1 Message Types" این RFC نوشته شده که :
Both messages may include optional
header fields (also known as "headers")
پس در نتیجه سرور و یا کلاینت در ارتباطاتشون با طرف مقابل می تونن هدرهای اختیاری داشته باشن.
همچنین در قسمت "5.2 Request Header Fields" نوشته شده:
However, new or
experimental header fields may be given the semantics of request
header fields if all parties in the communication recognize them to
be request header fields. Unrecognized header fields are treated as
Entity-Header fields.
گفته که "Unrecognized header" جزو "Entity-Header" حساب خواهند شد و طبق توضیحات "Entity-Header"، این ها، هدرهای هایی هستن که کلاینت در هر درخواست به سرور ارسال می کنه (البته همونطور که خودش هم توضیح داده انواع هدری دیگه ای هم وجود داره). پس در نتیجه Browser هایی که این RFC رو رعایت کرده باشن تمامی هدرهایی رو که شناسایی نکنن در درخواست بعدی به همون شکلی که دریافت کردن برای سرور پاس می کنن (یه مثال دیگه: فرض کنیم که این اتفاق نمی افتاد. یعنی هدرهایی که توسط کلاینت شناسایی نمی شدن به حال خودشون رها می شدن. و فقط و فقط هدرهایی رو که میشناختن دوباره به سرور پاس می کردن. در این صورت تمامی سایت هایی که هدر های خاص خودشون رو دارن مجبور بودن به IE و یا Firefox اعلام کنن که این هدرها رو توی نسخه های بعدی مرورگرهای خودشون ثبت کنن)
هیچ وقت هیچ هدری ذخیره نمی شه!!!
فقط کوکی که توی هدر منتقل میشه، باید توسط مرورگر و وب سرور تفسیر بشن و ذخیره بشن.
اون هدر هایی هم که شما نوشتید چیزی برای ذخیره شدن ندارند... بحثذخیره شدن رو من برای اون مورد شما گفتم، در حقیقت من هم می گم جز کوکی هیچی نمی تونه ذخیره بشه، هیچی!!!!!
به عنوان مثال وقتی که یه سایت از روی همین هدرهایی که از طرف کلاینت به سرور پاس شده نوع Browser رو تشخیص می ده ( و یا حتی نوع سیستم عامل کلاینت و ...) آیا داره چیزی از کلاینت می خونه؟ مسلما نه. اینها اطلاعاتی هستن که به دلخواه خود کلاینت به سرور فرستاده شده. شاید اگه جلمه "سایت نمی تونه و حق نداره چیزی جز کوکی رو بخونه" رو به جمله "سایت نمی تونه و حق نداره چیزی جز هدر ها رو چک کنه." تغییر بدیم بهتر باشه. چون کوکی هم جزو کل بزرگتری به اسم هدر است و درون هدر های قرار می گیره.
درسته، اما اینها کاملا استاندارد و فیکس هستند. کسی نمی تونه "فلان متغیر" رو هم به این لیست، به دلخواه خودش اضافه بکنه!! این توی استاندارد مرورگر های وب نیست. اگر می گی هست، منبع بیار.
با این جمله هم کاملا موافقم: "سایت نمی تونه و حق نداره چیزی جز هدر ها رو چک کنه."
پس در نتیجه سرور و یا کلاینت در ارتباطاتشون با طرف مقابل می تونن هدرهای اختیاری داشته باشن.
من با این قضیه مشکلی ندارم... اینو می دونم....
اما شما گفتی که اگر داخل هدر سرور به کلاینت هدر جدیدی باشه.... کلاینت هم اون مقدار جدید رو توی هدر request بعدی برای می فرسته!!!
همچنین در قسمت "5.2 Request Header Fields" نوشته شده:
However, new or
experimental header fields may be given the semantics of request
header fields if all parties in the communication recognize them to
be request header fields. Unrecognized header fields are treated as
Entity-Header fields.
گفته که "Unrecognized header" جزو "Entity-Header" حساب خواهند شد و طبق توضیحات "Entity-Header"، این ها، هدرهای هایی هستن که کلاینت در هر درخواست به سرور ارسال می کنه (البته همونطور که خودش هم توضیح داده انواع هدری دیگه ای هم وجود داره). پس در نتیجه Browser هایی که این RFC رو رعایت کرده باشن تمامی هدرهایی رو که شناسایی نکنن در درخواست بعدی به همون شکلی که دریافت کردن برای سرور پاس می کنن (یه مثال دیگه: فرض کنیم که این اتفاق نمی افتاد. یعنی هدرهایی که توسط کلاینت شناسایی نمی شدن به حال خودشون رها می شدن. و فقط و فقط هدرهایی رو که میشناختن دوباره به سرور پاس می کردن. در این صورت تمامی سایت هایی که هدر های خاص خودشون رو دارن مجبور بودن به IE و یا Firefox اعلام کنن که این هدرها رو توی نسخه های بعدی مرورگرهای خودشون ثبت کنن)
نه به این مفهوم نیست.
بیشتر دقت کن...
اول اینکه گفته "هدر یک درخواست" که ارسال میشه و هدر اضافی (ناشناس) توش هست اون موقع اون به صورت entity-header تفسیر میشه...
دوم تاکید می کنم که هدر ما چندین بخش داره، که تو بخش پنجم اون RFC کامل توضیح داده...
یعنی "عمومی" و "درخواست" و "محتویات" یا همون entity....
حالا اومده گفته که هدر های general اینها هستند و هدر های request اونها و مابقی هدر ها، هر چی باشه، به عنوان هدر entity شناخته میشن.
entity-header ها هم برای تفسیر entity-body لازمند.
همین حرکت در مورد response هم انجام میشه....
در حقیقت هیچ رابطه مستقیمی بین request و response وجود نداره و این مرورگر شماست که هر چی مناسب باشه توی هدر بعدیش میذاره تا ارسال بشه. و ***هیچ*** کدوم از این اطلاعات رو از "response" قبلی نمی گیره. (کوکی هم که ربط به دامنه داره و ربطی به response *قبلی* نداره)
خب من یه سوال دیگه برام پیش اومد
بعضی از صفحات شامل سه فیلد مخفی هست
خب من میام اول صفحه رو باز می کنم کد viewstate رو برمی دارم و می فرستم ولی جواب نمی ده
می خوام ببینم کسی در مورد این سه فیلد مخفی و یه فانکشن که ظاهراً خود asp ایجاد می کنه اطلاعاتی نداره؟
راستی اکسیژن جان قرار بود من خروجی phpinfo رو بهت بدم
به کجا بفرستم پیغام خصوصی دادم جواب ندادی اینجا گفتم
خب من میام اول صفحه رو باز می کنم کد viewstate رو برمی دارم و می فرستم ولی جواب نمی ده
می خوام ببینم کسی در مورد این سه فیلد مخفی و یه فانکشن که ظاهراً خود asp ایجاد می کنه اطلاعاتی نداره؟
فیلد ViewState برای نگه داره وضعیت اشیاء موجود در صفحه در asp .net استفاده می شه.
برای فیلد ViewState و سایر فیلد های مخفی موجود در صفحه، فقط کافیه که اسم و مقدار اونها رو مثل سایر فیلد ها ارسال کنی.
در مورد فانکش جاوا اسکریپت هم لازم نیست هیچ کاری انجام بدی، به حاله خودش رهاش کن...
ساندویچ پانل سردخانه، یک انتخاب هوشمندانه برای سرمایش مطمئن
