تبلیغات
تبلیغات متنی
محبوبترینها
قیمت انواع دستگاه تصفیه آب خانگی در ایران
نمایش جنگ دینامیت شو در تهران [از بیوگرافی میلاد صالح پور تا خرید بلیط]
9 روش جرم گیری ماشین لباسشویی سامسونگ برای از بین بردن بوی بد
ساندویچ پانل: بهترین گزینه برای ساخت و ساز سریع
خرید بیمه، استعلام و مقایسه انواع بیمه درمان ✅?
پروازهای مشهد به دبی چه زمانی ارزان می‌شوند؟
تجربه غذاهای فرانسوی در قلب پاریس بهترین رستوران‌ها و کافه‌ها
دلایل زنگ زدن فلزات و روش های جلوگیری از آن
خرید بلیط چارتر هواپیمایی ماهان _ ماهان گشت
سیگنال در ترید چیست؟ بررسی انواع سیگنال در ترید
بهترین هدیه تولد برای متولدین زمستان: هدیه‌های کاربردی برای روزهای سرد
صفحه اول
آرشیو مطالب
ورود/عضویت
هواشناسی
قیمت طلا سکه و ارز
قیمت خودرو
مطالب در سایت شما
تبادل لینک
ارتباط با ما
مطالب سایت سرگرمی سبک زندگی سینما و تلویزیون فرهنگ و هنر پزشکی و سلامت اجتماع و خانواده تصویری دین و اندیشه ورزش اقتصادی سیاسی حوادث علم و فناوری سایتهای دانلود گوناگون
مطالب سایت سرگرمی سبک زندگی سینما و تلویزیون فرهنگ و هنر پزشکی و سلامت اجتماع و خانواده تصویری دین و اندیشه ورزش اقتصادی سیاسی حوادث علم و فناوری سایتهای دانلود گوناگون
آمار وبسایت
تعداد کل بازدیدها :
1833896688
لوگین و مشاهده صفحه دیگر با curl -
واضح آرشیو وب فارسی:سایت ریسک: لوگین و مشاهده صفحه دیگر با curl msnasiri 19 مهر 1385, 13:01با سلام من می خوام با curl بیام به یه سایت لوگین کنم و بعد به صفحه دیگه برم مرحله لوگین درست انجام می شه من کوکی هایی که می خواد داخل لوگین انجام بشه رو می گیرم و به صفحه بعد می فرستم ولی باز داخل صفحه دوم می خواد که redirect کنه yasak 19 مهر 1385, 13:52سلام، تا جایی که می دونم بلاگفا بر اساس 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 مجانی زیادی روی اینترنت وجود داردن که یکی از اونها رو اگه نداری بگیر. msnasiri 19 مهر 1385, 16:54نمی دونم چرا قبلاً خراب کار می کرد امتحان کردم درست جواب داد البته با گذاشتن داخل فایل oxygenws 19 مهر 1385, 17:16تا جایی که می دونم بلاگفا بر اساس net. ساخته شده. توی net. حساسیت روی session های خیلی بیشتر از سایر تکنولوژی های وب هست و فقط با پاس کردن SessionID نمی شه یه session رو شبیه سازی کرد. علاوه بر SessionID یه سری پارامترهای دیگه (مثل یه سری تاریخ، یه سری عدد و ارقام و...) هم دوباره باید به صفحه .net پاس بشه تا بتونی session رو شبیه سازی کنی. زیاد این حرفت مفهومی نداره... سشن حداقل و حداکثر می تونه از کوکی استفاده کنه!! مابقی موارد.... به فرض هم که چیزی باشه، تاریخ، کلاینت یا هر چیز دیگه ای توسط مرورگر یا احیانا درخواست شما یا ... توسط curl مدیریت میشه و مشکلی باهاش نیست. امتحان کردم درست جواب داد بسیار عالی :) yasak 19 مهر 1385, 19:50سلام، سشن حداقل و حداکثر می تونه از کوکی استفاده کنه اگه ما فقط 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 متوسل شد. oxygenws 20 مهر 1385, 09:53در مورد همین مثالت.... یه header هم برگردونده بشه که مثلا بگه test=OK اونوقت این header کجا ذخیره میشه؟؟؟ سایت **نمی تونه** و **حق** نداره چیزی جز کوکی رو چک کنه. در حقیقت این مرورگر است که کوکی رو دوباره ارسال می کنه به سمت سرور و سرور چیزی از روی کلاینت نمی خونه. Browser ها تمامی هدر هایی رو که نمی شناسن رو دوباره در درخواست های بعدی به سرور به صورت خودکار پاس می کنن. اونهایی رو هم که می شناسن خوب طبیعتا پردازش می کنن و مقدار مناسبش رو به سرور بر میگردونن. و بنابراین استفاده از روش دوم(ترکیت سایر هدر ها علاوه بر session id) بدون مشکل امکان پذیره. چنین چیزی نیست، منبعی برای حرفت داری؟؟ ممنون. yasak 20 مهر 1385, 10:54سلام، اونوقت این header کجا ذخیره میشه؟؟؟ هدر لازم نیست جایی ذخیره بشه! همون طور که بقیه هدرهایی که بین سرور و کلاینت ردوبدل می شن ذخیره نمی شن (مگه در موارد خاصی که سرور یا کلاینت تصمیم به ذخیره کردن یه هدر خاص بگیره، که مصداقش هموم کوکی هست که کلاینت تصمیم می گیره از بین چندین هدر دریافت شده از یه سایت، اطلاعات موجود در هدر کوکی رو به عنوان یه کوکی ذخیره کنه). به عنوان مثال این لیست تعدادی از هدرهایی هست که شما وقتی صفحه اول گوگل رو می بینید به سرور ارسال می شه: GET / Host: 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 این هم تعداد از هدرهایی هست که گوگل به کلاینت برمیگردونه: 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 رو تشخیص می ده ( و یا حتی نوع سیستم عامل کلاینت و ...) آیا داره چیزی از کلاینت می خونه؟ مسلما نه. اینها اطلاعاتی هستن که به دلخواه خود کلاینت به سرور فرستاده شده. شاید اگه جلمه "سایت نمی تونه و حق نداره چیزی جز کوکی رو بخونه" رو به جمله "سایت نمی تونه و حق نداره چیزی جز هدر ها رو چک کنه." تغییر بدیم بهتر باشه. چون کوکی هم جزو کل بزرگتری به اسم هدر است و درون هدر های قرار می گیره. چنین چیزی نیست، منبعی برای حرفت داری؟؟ بله. این RFC مربوط به HTTP هست و قانون هایی که سرور و کلالینت برای ارتباط با هم باید رعایت بکنن رو توضیح می ده. در قسمت "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 اعلام کنن که این هدرها رو توی نسخه های بعدی مرورگرهای خودشون ثبت کنن) oxygenws 20 مهر 1385, 12:39همون طور که بقیه هدرهایی که بین سرور و کلاینت ردوبدل می شن ذخیره نمی شن هیچ وقت هیچ هدری ذخیره نمی شه!!! فقط کوکی که توی هدر منتقل میشه، باید توسط مرورگر و وب سرور تفسیر بشن و ذخیره بشن. اون هدر هایی هم که شما نوشتید چیزی برای ذخیره شدن ندارند... بحثذخیره شدن رو من برای اون مورد شما گفتم، در حقیقت من هم می گم جز کوکی هیچی نمی تونه ذخیره بشه، هیچی!!!!! به عنوان مثال وقتی که یه سایت از روی همین هدرهایی که از طرف کلاینت به سرور پاس شده نوع 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 کامل توضیح داده... Full-Request = Request-Line ; Section 5.1 *( General-Header ; Section 4.3 | Request-Header ; Section 5.2 | Entity-Header ) ; Section 7.1 CRLF [ Entity-Body ] ; Section 7.2 یعنی "عمومی" و "درخواست" و "محتویات" یا همون entity.... حالا اومده گفته که هدر های general اینها هستند و هدر های request اونها و مابقی هدر ها، هر چی باشه، به عنوان هدر entity شناخته میشن. entity-header ها هم برای تفسیر entity-body لازمند. همین حرکت در مورد response هم انجام میشه.... در حقیقت هیچ رابطه مستقیمی بین request و response وجود نداره و این مرورگر شماست که هر چی مناسب باشه توی هدر بعدیش میذاره تا ارسال بشه. و ***هیچ*** کدوم از این اطلاعات رو از "response" قبلی نمی گیره. (کوکی هم که ربط به دامنه داره و ربطی به response *قبلی* نداره) msnasiri 23 مهر 1385, 21:05خب من یه سوال دیگه برام پیش اومد بعضی از صفحات شامل سه فیلد مخفی هست خب من میام اول صفحه رو باز می کنم کد viewstate رو برمی دارم و می فرستم ولی جواب نمی ده می خوام ببینم کسی در مورد این سه فیلد مخفی و یه فانکشن که ظاهراً خود asp ایجاد می کنه اطلاعاتی نداره؟ راستی اکسیژن جان قرار بود من خروجی phpinfo رو بهت بدم به کجا بفرستم پیغام خصوصی دادم جواب ندادی اینجا گفتم yasak 23 مهر 1385, 21:16سلام، خب من میام اول صفحه رو باز می کنم کد viewstate رو برمی دارم و می فرستم ولی جواب نمی ده می خوام ببینم کسی در مورد این سه فیلد مخفی و یه فانکشن که ظاهراً خود asp ایجاد می کنه اطلاعاتی نداره؟ فیلد ViewState برای نگه داره وضعیت اشیاء موجود در صفحه در asp .net استفاده می شه. برای فیلد ViewState و سایر فیلد های مخفی موجود در صفحه، فقط کافیه که اسم و مقدار اونها رو مثل سایر فیلد ها ارسال کنی. در مورد فانکش جاوا اسکریپت هم لازم نیست هیچ کاری انجام بدی، به حاله خودش رهاش کن... msnasiri 23 مهر 1385, 22:39خب منم همین کار رو کردم ولی جواب نداد توضیحات کاملتر رو با پیغام خصوصی می گم
این صفحه را در گوگل محبوب کنید
[ارسال شده از: سایت ریسک]
[مشاهده در: www.ri3k.eu]
[تعداد بازديد از اين مطلب: 731]
-
گوناگون
پربازدیدترینها