سلام و عرض خسته نباشید
من برای اپدیت یک ستون توی دیتابیسم یک فرم درست کردم
به این صورت :
<form action="{{ route('update_product' , $requested_column->id ) }}" method="POST" enctype="multipart/form-data">
{{ method_field('PUT') }}
{{ csrf_field() }}
<input name="product_title" value="{{ $requested_column->title }}" id="product_title" type="text" class="form-control">
</form>
روت من :
Route::put('product/update/{id}', [ProductController::class , 'update'])->name("update_product");
کنترولر من :
public function update(Request $request , $id, Validator $validator){
$validator = $validator::make($request->all(), [
'product_title' => 'required|max:60',
'product_name' => 'required|max:60',
'product_description' => 'required|max:300',
]);
if ($validator->fails()) {
return redirect('users/products_list')->with("error" , 'مشکلی در اپلود فایل پیش امده است ');
}
Product::findOrFail($id);
}
خب این خیلی امنیتش ضعیفه اگه این قسمت از فرم رو دقت کنید :
<form action="{{ route('update_product' , $requested_column->id ) }}" method="POST" enctype="multipart/form-data">
کاربر خیلی راحت میتونه با ی expect element بیاد و مقدار id رو تغییر بده !!
چیکار کنم که نتونه تغییرش بده
id رو هش کنم؟؟
سلام
هر کاربر به چند تا product دسترسی داره؟
منظورم اینه که مثلاً این کاربری که داره این محصول رو آپدیت میکنه ، میتونه محصولات دیگر رو هم آپدیت کنه یا خیر؟
@ahmadrezabashari
با سلام.
روت هایی که کاربر قرار نیست بهشون دسترسی باشه اصلا نباید نمایش داده بشه! راحت ترین راه استفاده از middleware ها هست و بعد از اون موارد پیچیده تر Gates & Policies . در مواردی هم که نیاز دارید یوزر عادی چیزی رو اپدیت بکنه مثلا ویرایش کامنت ، ویرایش مقاله مربوط به نویسنده های سایت و ... ، اول باید مطمئن بشین که این کاربری که داره ریکوئست برای آپدیت آیتم شماره x میفرسته خودش نویسنده یا مالک اون آیتم x هست یا خیر و بعد برای آپدیت اقدام کنید.
سلام وقت بخیر ،
کاربر عادی اصلا نباید با این صفحه در ارتباط باشه !!
فقط باید خروجی رو ببینه.
شما باید پنل ادمین و روت های جاری سایت رو جدا کنید و با پرمیشن ها کنترل کنید چه کسی دسترسی داشته باشه
سلام @SobhanDadkhah @eniack
بله من از پرمیشن استفاده میکنم !!
کاربرای عادی به پنل ادمین دسترسی ندارن خیالتون راحت
ولی در رابطه با سوالی که کردم ...
زمانی که کاربر فرم رو ارسال میکنه در اونجا من ای دی شخص رو میگیرم
و اون رو تو قالب یک اینپوت ارسال میکنمش !
ولی کاربر میتونه با expect element مقدار ای دی رو تو اینپوت تغییر بده !!!
چیکار کنم نتونه؟؟؟
مقدار id رو هش کنم؟؟ راهنمایی بدین؟؟؟
اشتباه گفتم!! @ajdar9667
منظورم ای دی شخص نیست ای دی محصول هست
برای اپدیت محصول من ای دی محصول رو ارسال میکنم
به جای اینکه id محصول رو بفرستی خود محصول رو بفرست بعد داخل کد خودت از محصول به آیدیش برس
ببین به نظر من اول از خودت بپرس چرا میخوای محدودیت بزاری وقتی که ادمین به همه محصولات دسترسی داره و میتونه ویرایش کنه؟این فرم رو به غیر از ادمین کس دیگه ای نمیتونه ببینه و ادمین هم برای ویرایش محصول نیازی نداره که با inspect elements بیاد فرم رو تغییر بده ، بلکه خیلی راحت میتونه وارد فرم هر محصول بشه
ولی اگر باز هم میخوای ویرایش رو محدود کنی یه راهی که به ذهن من میرسه اینه که آی دی محصولی که ارسال شده رو با آدرس قبلی که کاربر چک میکرده مقایسه کنی و اگر یکی بودن ویرایش انجام بشه
url()->previous()
متودی هست که میتونه به url قبلی دسترسی داشته باشه
@ahmadrezabashari
با توجه به اطلاعات تازه ای که دادین دو نکته میگم خدمتتون:
1- زمانی که یک نفر داره محصول رو آپدیت میکنه و دسترسی مثل ادمین داره چرا باید آیدی رو دستی ارسال بکنه به فرم؟ در واقع در درجه اول این به ذهن هر کس میاد : تا زمانی که اعتماد نیست پس دسترسی هم نخواهد بود :))
2- حالا جدای از بحث دسترسی و برای تجربه بله روش کش که خودتون گفتین مناسبه. مثلا زمانی که میخواین فرم ویرایش رو نمایش بدین قبلش آیدی محصول رو کش کنید و وقتی درخواست ویرایش ثبت شد چک کنید که آیدی که کاربر فرستاده در آیدی های کش موجوده. ولی ملاحظات دیگه ای هم داره که باید حواستون بهش باشه اگر از کش استفاده میکنید مثلا بعد از اتمام عملیات آپدیت حتما باید اون آیدی از لیست آیدی ها پاک بشه و اینجور مسائل ریز:)
سلام
شما دو راه داری
یکی اینکه وقتی میخوای id رو بفرستی بیای از (id$)Crypt::encryptString
استفاده کنی این دستور یک ورودی میگیره و یه خروجی hash تحویل شما میده , وقتی هم که نیازه id رو داشته باشی از (hash$)Crypt::decryptString
استفاده میکنی اگر در مرحله قبل کاربر اون مقدار hash رو تغییر داده باشه اینجا بهش ارور میده
مستندات لاراول در مورد Crypt کامل توضیح داده
واقعا همه جا هم نیاز نیست این کارو انجام بدید وقتی مطمئن هستید خود ادمین مثلا به یه محیطی دسترسی داره گرچه بهتره انجام بشه
راه دوم هم اینه مثلا وقتی کاربر میخواد محصول رو اپدیت کنه خب اونجا چک کنی که اصلا ایشون دسترسی اینو داره یا نه که این عملیات رو انجام بده
@ahmadrezabashari
آیا مایل به ارسال نوتیفیکیشن و اخبار از طرف راکت هستید ؟