امضای دیجیتال درخواست های react و ولید کردن آن در Phoenix (بکند)

react

#1

با درود خدمت شما

قسمت فرونت من با قسمت api من که بکند باشه جداست به صورت مثال . حال من می خوام کلیه درخواست هایی که از react ام می یاد رو امضا کنم با jwt ولی فایل های ری اکت جاوااسکریپت هستند و کاربر می تونه به راحتی از داخل کد های js من کلید خصوصی jwt رو ببینه .

شما چه راه حلی برای این مشکل پیشنهاد می کنید . من حتما باید مطمئن می شم که این داده ها از سایت react من می یاد و ولید هستند .

تشکر


#2

این کار چه سودی داره؟ یعنی چه مشکلی رو برای شما حل میکمه؟
منظور از api و فرانت اند, json و html هست؟


#3

به سمت فرانت و کاربر هیچوقت نباید اعتماد کرد . باید ولیدیشن اصلی بکندت انجام بشه(توکن . نوع دیتا(جیسون . فرم دیتا).فیلدا . تایپ فیلدا و…)

بقول توماج عزیز اینکار چه فایده ای داره …
اینکار فقط باعث زحمت و سربار رو سایتت میشه


#4

دنبال این بود که کلا api رو پراویت کنم با اینکه لینکش پابلیک هست . چون قراره روی جوملا هم استفاده کنم نمی تونم درخواست رو با localhost بفرستم . پس گفتم دو طرف درخواست رو کد کنم .

اینجوری که سرچ کردم و بر اساس صحبت شما دو بزرگوار تو بکند باید توکن ایجاد کنم بعد از لاگین و توی هر درخواست توکن رو ارسال کنم برای بکند

درسته ؟

کلا api های من توماج جان به کل json هست


#5

به جوملا مثل یک سرویس نگاه کن که با توکن مخصوص خودش از api تغذیه میکنه


#6

یعنی سرویس جوملات روی یه سرور پابلیک دیگس؟؟ بازم فرق خاصی نمیکنه .
ولی بهتره میکروسرویسات کلا روی لوکال یا پرایویت نت ورک باشن … و هرچیزی ک قراره expose بشه با یه reverse proxy اینکارو بکنی


بررسی login شدن کاربر قبل از render شدن component لاگین در React
#7

من از وسط داستان صحبت کردم . اشتباه از من بود . کلا دوتا پروژه هست ولی

اونی که جوملا به این صورته جوملا روی دامنه اصلی هست که هم html و هم چندتا روتر داره که json api هست . حالا اون قسمتی که با ری اکت نوشته می شه دو جا قرار می گیره

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

شما در هاست اشتراکی چطور می خواهید چنین کاری رو بکنید . فکر کنید یک سی پنل داریم . حالا چطور می خواهید api رو فقط مخصوص لوکال بکنید. متاسفانه روی phoenix مشکل ندارم روی جوملاست مشکل دارم .

روی فونیکس با پابلیک api هم می تونم کار کنم چون کلا فلسفه سایت به این صورت بود که همه بتونند ازش خروجی و ورودی مشخص شده داشته باشند یا حتی می تونم درخواست هارو به localhost/api/create مثلا بفرستم ولی هاست اشتراکی بعید می دونم بشه


#8

میتونی یه کاستوم هدر ست کنی به ریکوئست های جوملات … ک متوجه بشی از رو اون دارن میان … چون به هرصورت وقتی ریکوئست میزنی… سرویس فوئنیکست اگه جلو نباشه … نمیتونه بفهمه … (اینجور ک فهمیدم ری اکت(فرانت اند) جلو هست) … بنابرین .هرریکوئستی ک میخوره ب سایتت … از روی دامینت / فرانتت رد میشه … ولی برای شناختن خود فرانتت راهکاری به نظرم نمیرسه. و بهتر هم هست ک روش وقت نزاری


#9

دوتا ssl هم (یکی رو جوملا یکیم فوئنیکس) ست کن … تا نتونن ریکوئستا رو بدزدن … و بفهمن چی بینشون ردو بدل میشه(تا نتونن سرویس جوملاتو فیک بسازن . .و بجاش ریکوئست بزنن)


#10

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

به نظرم روی api دقیق تر تمرکز کنم خیلی بهتر از این مورد هست. فقط می مونه ارسال آیپی کاربر در سایت های ری اکتی به بکند فونیکسی که خودش باز یک چالشه . که چطور از ری اکت آیپی واقعی کاربر رو به بکند فرستاد که اون سری بحث شد که بازم به هر صورت کاربر قادر به تغییر آیپی خودش هست. پس در حقیقت زیاد فایده ای خاصی نداره :expressionless: :disappointed_relieved:

تشکر از دوست خوبم @salvador و همینطور توماج عزیز


#11

یه توصیه دارم شهریارجان . برای اینکه کنترل بیشتری روی apiهات داشته باشی .اونم دسته بندی و ورژن بندی هست

به نظرم apiهای پابلیکتو از apiسرویس ها با یه پرنت روت جدا کن
/pub/blog/posts/get
/joomla/blog/posts/get


v1/pub/blog/posts/get
v2/pub/blog/posts/get

اینا رو من سر یک سری پروژه هام انجام ندادم … تو آپدیت … و سرویس دادن به یک سری کلاینت ها یکم دچار مشکل شدم(موبایل یک سری چیزای اضافی تری میخاست . فرانت یک سری نیاز های دیگه)

البته خودت استادی. جسارت نمیکنم … احتمالا هم انجامش دادی … صرف توصیه بود


#12

بله حق با شماست . بنده هم در پروژه اولم سام عزیز اینارو بهم گفت و خودم واقعا تجربه کردم چه بلایی سر آدم می یاد.

من حتی در آینده اگر بخوام api دیگه ای بزنم حتی بخش admin رو هم جدا می کنم . چند مدل ساخت از یک فانکشن برخی مواقع خیلی خوبه ولی بعد از مدتی متوجه شدم انقدر کد زدم با داکیومنتی که خوب نوشتم هم نمی تونم برگردم بهش . چون می خواستم به زور یک api واحد بنویسم . به نظرم ادمین سایت هم بخاطر تنظیمات زیاد و دسترسی های گزینشی هم باید جدا بشه و ورژن بندی بشه

این مشکل رو اسنپ هم داشته بخاطر ورژن بندی نکردن یک بار جلوی کل کاربراشو گرفته کلا افزونه رو آبدیت کنند

عزیزم ما کوچیک شماییم اینا چه حرف هایی هست من از وقتی این انجمن اومدم فهمیدم کلا داشتم راه رو اشتباه می رفتم که هیچ داشتم نابود هم می کردم :grin:
بنده کارآموزشم و ممنونم که از تجربیات خودتون استفاده می کنید برای یاد دادن به من و افرادی مثل من که تازه وارند


#13

سلام
منم یک سوال در این مورد داشتم.
وقتی یک app که از فایربیس به عنوان دیتابیس استفاده میکنه و کد api داره حالا این app کجا باید این کد api رو بذاره خب مطمئنا این کد در سمت کلاینت هم هست ودیده میشه و هر کس که بتونه به کد دسترسی داشته باشه خب به دیتابیس هم دسترسی داره
در این موارد چاره چیه؟
ویرایش: بعد از فکر کردن فهمیدم که تنظیماتی تو فایربیس هست که خودمون میتونیم read, write رو تنظیم کنیم و اینکه چه کسایی حق دسترسی دارند. ولی اینکه کد api در دسترس باشه مشکلی نداره؟


#14

اصولش اینه شما بکند داشته باشید . و ریکوئستا از سمت سرورتون رد بشه برسه به فایربیس … تا هم بتونید لاگ نگه دارید . هم نتایج رو .هم اینکه کسی کد apiتونو نمیبینه …

و همینطور اگه بشه تنظیم کرد و domain baseاش کرد … مشکلتون حل میشه تا حدود زیادی.


#15

ببخشید منظورتون از domain base چیه؟


#16

گیرنده ریکوئست میتونه از هدر ببینه که از کدوم domain ارسال شده ریکوئست . مثل درگاه های پرداخت .
البته توی rest احتمالا بشه تغییرش داد … بنابرین توی redirect چک میکنن تو مرحله آخر … ک از دامین درست داره ارسال میشه یا نه


#17

درود خدمت دوست عزیز . من یک پست دادم هرچی می گردم پیدا نمی کنم . اون می گفت محدود سازی بر اساس دامنه زیاد کارایی نداره اونم قابل دور زدنه . یا من توهم زدم ؟ :grin::thinking:


#18

اونم قابل دور زدنه . ولی redirect رو نمیدونم :thinking: کلا همه چیز قابل دور زدنه :smile:


#19

این بنده خدا میخواد JWT رو sign بکنه و این موضوع رو ربطی به Origin نداره. شما خیلی راحت میتونی اینکار رو انجام بدی بیشتر کتابخونه‌هایی که JWT رو پیاده کردن این اجازه رو به شما میدن که JWT رو sign بکنی. برای مثال توی یکی از پروژه‌هام و البته با کتابخونه jwt روبی:

payload = {
  iss: 'ejare.games',
  exp: 100.seconds.from_now.to_i,
  user_id: user.id
}

JWT.encode(payload, private_key, 'RS256', typ: 'JWT')

که مثال اصلی رو میتونی اینجا ببینی:

یک مسئله دیگه‌؛ شما نباید چک کنی که از چه سایتی میاد (اون یک مسئله دیگه‌ست) برای امضا کردن کلید‌های JWT باید سمت سرور با private key و مدل رمزنگاری امضا بشن و موقعی که از سمت front-end برمیگردن با public key و مدل رمزنگاریش چک بکنی که توسط private key که خودت استفاده کردی امضا شده باشه.

  def token_valid?(token, public_key = Keychain.last.public_key)
    true if JWT.decode(token, public_key, true, algorithm: 'RS256')
  rescue JWT::DecodeError
    false
  end

این هم یک نمونه دیگه که من دقیقا این کار رو انجام میدم.


#20

شاید من یکمی با پرسش در مورد اینکه این کار چه فایده ای داره داستان سختی درست کردم، اما منظور من این نبود که این کار درسته یا نادرست، منظور من دقیقا پیدا کردن مشکل اصلی و ایجاد جو‌ لازم برای حل کردن اون بود.
چیزی که بهش میگیم interrogation session

image