معمولا روحیات و فرهنگ یک کشور در اقبال مردم نسبت به انتخاب یک شبکه اجتماعی خاص تاثیر دارد و گاهی ممکن است انتخاب یک شبکه اجتماعی خاص از طرف آحاد مردم با خواسته دولت ها و یا مصلحت کشور متفاوت باشد. ولی نکته بدیهی آن است که شبکه های اجتماعی میتوانند یکی از مولفه های تاثیرگذار در فرهنگ، اقتصاد و امنیت یک کشور باشد. امروزه اهمیت استراتژیک شبکه های اجتماعی بر کسی پوشیده نیست. حتی گاهی کشورهای سازنده این سرویس ها از آثار مخرب این شبکه ها در کشور خود نگران میشوند. شبکه های اجتماعی گاهی با عنوان شبکه های پیام رسان و گاهی با نام رسانه های اجتماعی نامگذاری می شوند. و در یک تقسیم بندی کلان به دو دسته تقسیم میشوند.
الف)شبکه های اجتماعی مبتنی بر وب مثل فیس بوک
ب)شبکه های اجتماعی موبایلی مثل تلگرام
معمولا عمده ی سرویس دهنده های شبکه های اجتماعی اجازه جمع آوری اطلاعات به صورت محدود (از نظر حجم و هم از نظر نوع اطلاعات) را با واسطه های نرم افزاری (API) امکان پذیر میسازند. البته سطح استفاده از این API ها متفاوت است ولی نکته بدهی آن است که سرویس دهنده های شبکه های اجتماعی صرفا اجازه جمع آوری اطلاعات آشکار از این شبکه ها را می دهند و از ارائه اطلاعات محرمانه ی افراد مثل محتوای PMها و آن قسمت از اطلاعاتی که کاربران در تنظیمات شبکه خود مخفی اعلام کرده اند برای عموم ممانعت میکنند. هر چند شاید به راحتی این اطلاعات در اختیار سرویس های اطلاعاتی قرار میدهند و یا می فروشند. البته راه کار هایی برای استخراج برخی اطلاعات محرمانه کاربران تا کنون ارائه شده است که به موضوع های دانشی مباحث ما ارتباطی پیدا نمی کند.
در این مبحث به ارائه روش های جمع آوری قانونی اطلاعات (از دید سرویس دهنده توئیتر) از شبکه ی با اهمیت توئیتر می پردازیم. معمولا جمع آوری اطلاعات در هر شبکه اجتماعی نیاز به سه فاز اصلی زیر دارد. که در این مبحث این سه فاز را برای شبکه اجتماعی توئیتر بررسی میکنیم.
- فاز اول تایید هویت در توئیتر
- فاز دوم اتصال به رابط ارائه شده (API) جمع آوری اطلاعات در توئیتر
- فاز سوم جمع آوری اطلاعات از توئیتر
فاز اول تایید هویت در توئیتر
شما به احتمال زیاد از وبسایت‌ها یا برنامه های موبایلی استفاده می‌کنید که به جای شما در وبسایت‌ها یا سرویس‌های دیگر کاری انجام میدهند. به طور مثال اگر اکانت توییتر دارید، احتمالاً از یک کلاینت توییتر روی دسکتاپ یا موبایل‌تان استفاده کرده‌اید. یا از طریق اپلیکیشن موبایل وردپرس فعالیتهای وبلاگ‌تان را دنبال می‌کنید. در همه‌ی این موارد شما از استانداردهای تایید هویت ستفاده کرده‌اید. تایید هویت در این مقوله معمولا به دو روش انجام میشود.
- OAuth
- OpenID
با اینکه این دو استاندارد در نگاه اول شبیه هم هستند اما تفاوت‌های زیادی دارند و در واقع کارهای مختلفی انجام میدهند. OpenID به این درد می‌خورد که به وسیله‌ی یک اکانت در چندین سایت مختلف ثبت‌نام کنید و به این ترتیب دردسر به خاطر سپردن نام‌های کاربری و پسوردهای مختلف را نداشته باشید. اما به وسیله OAuth شما به یک اپلیکیشن یا وبسایت (مصرف‌کننده) اجازه می‌دهید به جای شما در یک سرویس دیگر (ارائه‌دهنده) کاری انجام دهند. درواقع شما در هنگام استفاده از OAuth باید در سرویس ارائه‌دهنده لاگین کنید. یعنی نام کاربری و پسورد خود را در آنجا وارد کنید و سپس اجازه‌ی دسترسی به مصرف‌کننده را بدهید. اینکه ارائه‌دهنده شما را با چه وسیله‌ی لاگین می‌کند ربطی به OAuth ندارد. حتی می‌توانید برای لاگین کردن از OpenID استفاده کنید.
محل استفاده از OAuth
OAuth به این درد می‌خورد که شما بدون اینکه نام کاربری و پسوردتان را با مصرف‌کننده به اشتراک بگذارید به او اجازه دهید به جای شما فعالیت کند. شما نام کاربری و پسورد را در سایت ارائه‌دهنده وارد می‌کنید و وارد حساب کاربری خود می‌شوید، در آنجا ارائه‌دهنده به شما اعلام می‌کند که مصرف‌کننده قصد انجام چه کارهایی را دارد و از شما برای صدور مجوزهای لازم اجازه میگیرد. هر زمان هم که نیاز داشتید می‌توانید دسترسی مصرف‌کننده را از طریق سایت ارائه‌دهنده مسدود کنید. مزیت این روش وقتی مشخص‌تر میشود که چندین مصرف‌کننده بخواهند از طرف شما به یک ارائه‌دهنده متصل شوند. اگر روزی بخواهید دسترسی تمام مصرف‌کننده‌ها را قطع کنید لازم نیست نام کاربری و پسوردتان را از تک تک آنها حذف کنید.
مراحل کارکرد OAuth
فرض کنید یک اپلیکیشن موبایل دارید به اسم Uploader دارید که می‌خواهد یک عکس را در یک سایت آپلود عکس به اسم Images قرار دهد. شما یک اکانت در سایت Images دارید اما نمی‌خواهید نام کاربری و پسوردتان را در اپلیکیشن Uploader ذخیره کنید. برحسب اتفاق اپلیکیشن Uploader به شما این امکان را می‌دهد که از طریق OAuth اجازه دسترسی را صادر کنید. اتفاقی که می‌افتد به قرار زیر است:
- اپلیکیشن Uploader به وبسایت Images یک درخواست می‌فرستد مبنی بر اینکه می‌خواهد از طرف یک کاربر به سایت دسترسی پیدا کند.
- سایت Images یک توکن یا نشانه (یک رشته یکتا از حروف، اعداد و کاراکترها) به اپلیکیشن می‌فرستد. این نشانه موقتی است و بعد از گذشت مدت زمان معینی منقضی میشود.
- اپلیکیشن Uploader کاربر را به وبسایت Images راهنمایی می‌کند. وبسایت از طریق نشانه مرحله ۲ می‌فهمد که اپلیکیشن Uploader کاربر را راهنمایی کرده.
- کاربر نام کاربری و پسورد خود را در وبسایت Images وارد می‌کند.
- وبسایت Images به کاربر اطلاع می‌دهد که اپلیکیشنی به نام Uploader می‌خواهد به جای او در وبسایت کاری انجام دهد.
- اگر کاربر تصمیم گرفت که اجازه را صادر کند، وبسایت Images همان نشانه‌ای را که در مرحله ۲ صادر کرده بود برای اپلیکیشن می‌فرستد و او را مطلع می‌کند.
- اپلیکیشن Uploader درخواست دیگری برای وبسایت Images می‌فرستد و از او می‌خواهد نشانه‌ای دائمی به کاربر اختصاص دهد.
- وبسایت Images نشانه را تولید می‌کند و به اپلیکیشن می‌فرستد.
- اپلیکیشن Uploader عکس را به همراه نشانه‌ی دائمی برای وبسایت Images می‌فرستد.
- وبسایت Images عکس را آپلود می‌کند.
نحوه کارکرد فنی و نرم افزاری OAuth
عکس زیر به طور کامل و واضح مراحلی که مصرف‌کننده و ارائه‌دهنده باید طی کنند تا مصرف‌کننده اجازه‌ی دسترسی داشته باشد را نشان می‌دهد. دقت کنید که این مراحل مربوط به وبسایت Flickr است و بعضی پارامترها را سرویس فلیکر اضافه کرده است و عمومیت ندارد
پارامترهای هر درخواست و جواب بسیار مهم هستند و اگر یکی از آنها اشتباه فرستاده یا محاسبه شود، کل عملیات متوقف میشود. در اینجا هرکدام از پارامترها را توضیح می‌دهم:
گام اول اجازه‌ی دسترسی با OAuth
در مرحله اول مصرف‌کننده یک درخواست به ارائه‌دهنده می‌فرستد و درخواست یک request token می‌کند.
- oauth_consumer_key: این پارامتر یک مقدار است که توسط ارائه‌دهنده به ازای هر مصرف‌کننده به صورت یکتا تولید میشود. معمولاً از طریق پنل ارائه‌دهنده این مقدار قابل تولید و نمایش است. پیش از فرستادن درخواست، مصرف‌کننده باید این مقدار را از ارائه‌دهنده گرفته باشد.
- oauth_nonce: این پارامتر یک مقدار منحصر به فرد به ازای هر درخواست است. مصرف‌کننده باید این مقدار را تولید و از یکتا بودن آن اطمینان پیدا کند. راجع به nonceها در اینجا بیشتر بخوانید.
- oauth_signature_method: یکی از مقادیر «HMAC-SHA1» یا «RSA-SHA1» یا «PLAINTEXT». به غیر از PLAINTEXT بقیه متدهای رمزنگاری درخواست هستند. به احتمال خیلی زیاد زبانی که از آن استفاده می‌کنید کتابخانه‌ی مخصوص این رمزنگاری‌ها را دارد. اگر مقدار این پارامتر برابر با PLAINTEXT باشد پارامترهای oauth_timestamp و oauth_nonce اختیاری میشوند.
- oauth_signature: درخواستی که مصرف‌کننده می‌فرستد باید امضا شود. این امضا بعداً توسط ارائه‌دهنده بار دیگر محاسبه میشود و فقط در صورتی که با امضای فرستاده شده برابر بود، درخواست پاسخ داده میشود. نحوه‌ی محاسبه‌ی امضا نیاز به توضیحات بیشتری دارد که در این پست نمی‌گنجد (بخش راجع به امضا را نگاه کنید)
- oauth_timestamp: تعداد ثانیه‌های گذشته از نیمه‌شب ۱ ژانویه ۱۹۷۰٫ این پارامتر برای این به کار می‌رود که ارائه‌دهنده بداند درخواست در چه لحظه‌ای فرستاده شده است. با این پارامتر اگر به طور مثال پنج دقیقه از فرستاده شدن درخواست گذشته باشد میشود درخواست را رد کرد زیرا ممکن است مشکلی در سر راه به وجود آمده باشد.
- oauth_callback: آدرس معتبری که مصرف‌کننده روی آن انتظار جواب ارائه‌دهنده را می‌کشد. ارائه‌دهنده پارامترها را بررسی و جواب‌ها را آماده می‌کند و به این آدرس می‌فرستد. این پارامتر درواقع اختیاری است اما بهتر است صراحتاً فرستاده شود تا به طور کامل بتوان ریدایرکت‌ها را کنترل کرد. اگر مصرف‌کننده یک دستگاه (مانند تلفن همراه) باشد، این آدرس دیگر با پروتکل http عرضه نمی‌شود و باید پروتکلی که درواقع وجود ندارد را به کار برد. زیرا می‌خواهیم پارامترهایی که توسط این آدرس فرستاده میشود را به وسیله اپلیکیشن (و نه یک مرورگر) مدیریت کنیم. به طور مثال oauth_callback در یک اپلیکیشن اندروید می‌تواند myapp://authorize باشد و توسط intentها مدیریت شود. اینجا توضیحات خوبی داده شده است.
- oauth_version: این پارامتر اختیاری است. اما اگر فرستاده شود باید نسخه OAuth که استفاده میشود را فرستاد. در اینجا باید مقدارش ۱٫۰ باشد.
ارائه‌دهنده request token را به آدرس callback مصرف‌کننده می‌فرستد.
- oauth_token: یک رشته‌ی یکتا. این توکن که با نام request token هم شناخته میشود، موقتی است و بعد از چند دقیقه یا چند ساعت (بسته به تنظیمات ارائه‌دهنده) منقضی میشود. این پارامتر برای مرحله‌ی بعد که کاربر باید به سایت ارائه‌دهنده ریدایرکت شود به درد می‌خورد.
- oauth_token_secret: این پارامتر در محاسبه امضا مورد استفاده قرار میگیرد. (بخش راجع به امضا را نگاه کنید)
- oauth_callback_confirmed: مقدارش فقط true است و هیچوقت false نمی‌شود. در واقع برای فرق گذاشتن بین نسخه‌های مختلف پروتکل استفاده میشود.
گام دوم اجازه‌ی دسترسی با OAuth
در مرحله دوم مصرف‌کننده، کاربر را به سایت ارائه‌دهنده ریدایرکت می‌کند. با این پارامترها:
- oauth_token: که همان توکن تولید شده در مرحله قبل است.
- oauth_callback: که همان شرایط مرحله قبل را دارد.
ارائه‌دهنده کاربر را لاگین می‌کند و به او پیغام می‌دهد که یک مصرف‌کننده می‌خواهد از طرف او فعالیتی انجام دهد. کاربر تصمیم میگیرد که این اجازه را بدهد یا نه. اگر کاربر اجازه را صادر کرد، به آدرس مصرف‌کننده این پارامترها فرستاده میشود:
- oauth_token: که همان توکن مرحله قبل است.
- oauth_verifier: این پارامتر یک رشته‌ی یکتا است که در مرحله بعد مورد استفاده قرار میگیرد.
گام سوم اجازه‌ی دسترسی با OAuth
در مرحله سوم مصرف‌کننده یک درخواست برای یک توکن دیگر به نام access token می‌فرستد. با این پارامترها:
- oauth_consumer_key: همان پارامتر در مرحله اول است.
- oauth_nonce: یک nonce یکتای دیگر برای این درخواست.
- oauth_signature_method: همان پارامتر در مرحله اول است.
- oauth_signature: همان پارامتر در مرحله اول است با این تفاوت که با توجه به پارامترهای فعلی مقدارش محاسبه میشود.
- oauth_timestamp: همان پارامتر در مرحله اول است. با این تفاوت که تعداد ثانیه‌های گذشته تا این لحظه (یعنی لحظه‌ی فرستادن درخواست مرحله سوم) باید منظور شود.
- oauth_verifier: این پارامتر با مقداری که از ارائه‌دهنده دریافت شده است پر میشود تا معتبر بودن درخواست در مرحله سوم احراز شود. اگر این پارامتر با مقداری که ارائه‌دهنده پیش خود نگاه داشته است فرق داشته باشد، عملیات متوقف میشود و توکن اختصاص داده نمی‌شود.
- oauth_version: که همان پارامتر در مرحله اول است.
ارائه‌دهنده یک توکن دائمی به مصرف‌کننده اختصاص می‌دهد و آن را برای او می‌فرستد.
- oauth_token: یا access token یک توکن دائمی است که مصرف‌کننده برای دسترسی به آدرس‌ها از آن استفاده می‌کند.
- oauth_token_secret: این پارامتر در محاسبه‌ی امضا مورد استفاده قرار میگیرد. (راجع به امضا)
وقتی مصرف‌کننده این مقادیر را از ارائه‌دهنده دریافت می‌کند، می‌تواند به جای کاربر از امکانات ارائه‌دهنده استفاده کند. به این صورت که با هر درخواست پارامترهای زیر را می‌فرستد:
- oauth_token: همان secret token که از ارائه‌دهنده دریافت کرده است.
- oauth_consumer_key: همان پارامتر در مرحله اول است.
- oauth_signature_method: همان پارامتر در مرحله اول است.
- oauth_timestamp: همان پارامتر در مرحله اول است با این تفاوت که تعداد ثانیه‌های گذشته تا لحظه‌ی فرستادن این درخواست باید لحاظ شود.
- oauth_nonce: یک nonce یکتای دیگر برای این درخواست.
- oauth_signature: همان پارامتر مرحله اول است با این تفاوت که با توجه به پارامترهای فعلی مقدار آن محاسبه میشود.
تشریح امضا
درخواست‌ها باید امضا شوند تا فرستنده‌ی هر درخواست مشخص شود. امضاها توسط کلیدهای مخفی (secret key) که فقط در اختیار مصرف‌کننده و ارائه‌دهنده قرار دارند رمزنگاری میشوند و به همین دلیل احتمال تقلب در ارسال درخواست توسط اسکریپت‌های دیگر بسیار پایین می‌آید. محاسبه‌ی امضا گرچه کار چندان سختی نیست، اما نیاز به دقت فراوان دارد. مراحل تولید امضا در اینجا به صورت دقیق بیان شده است. بر هر برنامه‌نویسی واجب است که آن را بخواند و به کار بگیرد.
تایید هویت در توئیتر معمولا به دو صورت انجام میگیرد که هر دو از OAuth 1.0A استفاده می کنند.
- User authentication :
- Application-only authentication
User authentication : در این روش شناسه application و اجازه end-user برای برقراری ارتباط نیاز است.
Application-only authentication : در این روش با application ساخته شده بدون ارتباط با کاربر ارتباط برقرار می کند. ودر این روش محدودیت ها به اضای هر کاربر به ازای هر برنامه می باشد . و نرخ این محدودیت بیشتر می باشد ولی همه API ها این روش را پشتیبانی نمی کنند چون به یک کاربر logged-in نیاز دارند.(مانند ایجاد توئیت)
کارکرد هایی که در زیر ذکر شده از طریق این روش امکان پذیر است:
- Pull user time lines
- Access frinds and flowers of any account
- Access lists resources;
- Search in tweets
- Retrive any user information
و انجام موارد زیر با این روش امکان پذیر نمی باشد:
- Post tweets or other resources
- Connect in streaming endpoints
- Search for users
- Use any geo endpoint
فاز دوم اتصال به رابط ارائه شده (API) جمع آوری اطلاعات در توئیتر
بعد از مرحله اول یعنی تایید هویت که در بالا اشاره شد میبایست با اتصال به رابط های مشخص شده مرحله دوم کار یعنی اتصال به رابط جمع آوری را انجام داد. دسترسی به اطلاعات از توییتر از دو طریق زیر امکان پذیر است.
- روش اول REST
- روش دوم stream API
روش اول REST
این روش اجازه پرس و جو و تغییر یک حساب کاربری را می دهد. برای پرس و جو (read) نیازی به مجوز حساب های آن ها نیست ولی برای تغییر (write)حساب کاربری، باید از طریق OAuth مجوز این کار را بدهند.
| احراز هویت توئیتر |
در این روش فراخوانی های زیر قابل استفاده می باشند.(واحد نرخ محدودیت تعداد درخواست ها در پنجره زمانی می باشد که طول پنجره زمانی ۱۵ دقیقه می باشد) (۲)
- GET statuses/user_timeline
۳۲۰۰ تویت آخر کاربر را برمی گرداند(هر درخواست یک صفحه با حداکثر ۲۰۰ تویت)محدودیت: ۱۸۰ فراخوانی برای حالت کاربر- و ۳۰۰ فراخوانی در حالت برنامه)
- GET statuses/lookup
حداکثر ۱۰۰ تویت را از روی id هایشان برمیگرداند(۱۸۰ فراخوانی برای حالت کاربر و ۶۰ فراخوانی برای حالت برنامه)
روش دوم stream API
از طریق stream api میتوان توئیت ها را بر اساس کلمات کلیدی یا کاربران مورد نظر درخواست کرد(read)، برای این کار نیازی به مجوز کاربران نیست.در این روش دریافت اخبار به صورت آنی می باشد.
فاز سوم جمع آوری اطلاعات از توئیتر
در کل سه نوع فراخوانی متصور است:
۱. دریافت تویت های جدید یک حساب، برای اینکار می توان از جریان استفاده نمود.
۲. بروزرسانی تویت های جدید یک حساب در یک بازه اولیه زمانی تا بدانیم تغییرات مربوط به لایک ها و همرسانی های آن به چه صورت می باشد تا اگر داغ شد آن را تشخیص دهیم. این امر با جریان امکان پذیر نمی باشد. ولی در صورت استفاده از روش REST این فراخوانی تویت های جدید هر اکانت را نیز خواهد داد.
۳. بروزرسانی تویت های اکانت های مختلف که داغ شده اند تا زمانی که از داغی بیافتند تا بدانیم تا چه زمانی داغ هستند و کی از داغی می افتند. این امر نیز با جریان امکان پذیر نمی باشد. خوشبختانه twitter api خود به صورت ضمنی از فراخوانی دسته ای بدین منظور پشتیبانی می کند که می توان از آن برای این کار استفاده نمود.
اگر دقت شود فراخوانی نوع دوم، فراخوانی نوع اول را نیز پوشش می دهد و بنابراین نیازی به فراخوانی نوع اول به صورت مستقل و با استفاده از جریان نمی باشد.
برای فراخوانی های نوع اول و دوم با محوریت کاربران تویتر از فراخوانی GET statuses/user_timeline استفاده شود.
برای فراخوانی نوع دوم با محوریت شماره id تویت ها از فراخوانی GET statuses/lookup استفاده گردد.
تویت ها دارای اطلاعاتی مانند تعداد favorite،retweet و comment می باشند. که api twitter تعداد کامنت ها را در اختیار نمی گذارد ولی متن کامنت ها را می دهد .
کتابخانه های twitter api :
- twitter4j
محبوبترین کتابخانه جاوا برای تویتر که استفاده از آن ساده می باشد. این کتابخانه غیر رسمی است.
- java-twitter
یک اینترفیس جاوایی برای تویتر. توسعه این کتابخانه مدت ها پیش متوقف شده است و به نسخه ۱ هم حتی نرسیده.
- jtwitter
کتابخانه کوچک برای دسترسی ساده به تویتر که بیشتر کاربرد شخصی دارد. - spring social
بر اساس RestTemplate متعلق به spring-web بوده و یکپارچه و هماهنگ می باشد.
- twitter-hbc
برای پشتیبانی از stream در تویتر می باشد.
از میان این کتابخانه ها دو کتابخانه twitter4j و spring social مناسب تر هستند.
نقاط قوت استفاده از spring social
۱.چون معماری پروژه بر اساس spring می باشد از نظر اصل معماری یکپارچه ترجیح بر استفاده از spring social هست که در دایره معماری/ادبیاتی spring تعریف می گردد.
۲. اینطور که به نظر می رسد کلیات api ارائه شده در spring social برای تویتر و فیسبوک و … مشابه می باشد و این موجب یکپارچه تر شدن پروژه برای شبکه های اجتماعی مختلف (فیسبوک، تویتر و حتی اینستاگرام و …) می شود.
۳. از منظر مباحث مهندسی نرم افزار مثل بروز بودن کتابخانهُ، زنده بودن کتابخانه(بیشتر مورد استفاده عمومی باشد و اشکالات آن پیدا و رفع شود)، داشتن نسخه های جدیدتر و … به نظر می رسد spring social چون تحت حمایت مجموعه بسیار قوی تری نسبت به twitter4j است
نقاط ضعف spring social
ترجیح استفاده به سمت spring social می باشد.ولی این کتابخانه متاسفانه فراخوانی GET statuses/lookup را پشتیبانی نمی کند. در نتیجه از twitter4j برای twitter api استفاده خواهد شد.
twitter4j
مهمترین مزیت استفاده از این کتابخانه پشتیبانی از اکثر فراخوانی های twitter api به خصوص فراخوانی GET statuses/lookup می باشد. همچنین این کتابخانه با Twitter API 1.1 نیز سازگار است.
------------------------------------------------
منبع : خانه بیگ دیتای ایران
