01/10/2018, 12:10

Làm sao daynhauhoc biết bài viết của mình để cho phép sửa nhỉ?

Mình thắc mắc không biết tại sao trang daynhauhoc biết bài viết của mình để cho phép sửa nhỉ? cơ chế như thế nào? ace nào biết giải thích hộ với?

Dark.Hades viết 14:26 ngày 01/10/2018

Tạo table
posts

id
user_id
...

Kiểm tra user_id trùng với logging_in user_id trên browser rồi thực hiện logic/render html

Thuc Nguyen Tan viết 14:18 ngày 01/10/2018

user_id nằm trên client hay server bạn?
ví dụ:
XXX://daynhauhoc.com/t/lam-sao-daynhauhoc-biet-bai-viet-cua-minh-de-cho-phep-sua-nhi/57041
số 57041 là id hay user_id?

Dark.Hades viết 14:17 ngày 01/10/2018

Trên client chỉ có session/cookie, và URL. server sẽ kiểm tra các thông tin đó rồi thực hiện logic (SELECT database, render, respond,…)

số 57041 là id hay user_id?

id post

Thuc Nguyen Tan viết 14:16 ngày 01/10/2018

Vậy user_id không có view ở client?
server sẽ vào database để xác nhận thông tin?
Có chỗ nào khác lưu user_id không bạn;
Ví dụ:
var resource={post_id:‘xx’,user_id:‘yyyy’}
để kiểm tra luôn? vì chỉ cần 1 cặp số này thôi

Dark.Hades viết 14:22 ngày 01/10/2018

Bạn tự render phía server thì client mới có thông tin mà đọc chứ?

Thuc Nguyen Tan viết 14:24 ngày 01/10/2018

à mình quên, mình đã có thông tin user_id ở token , vậy thế này nhé,

posts(id,user_id, … )

  • user sẽ change trong phần …, post gửi trả về server
  • Server sẽ check token nếu ok sẽ update vào csdl, không cần qua kiểm tra nữa.
    Liệu có an toàn không?
Dark.Hades viết 14:13 ngày 01/10/2018

Không bao giờ tin tưởng dữ liệu mà client có thể chỉnh sửa.
Bình thường các ngôn ngữ support server/client HTTP sẽ kèm theo 1 kiểu session, lưu thông tin của người dùng(browser) trên server, client không thể làm gì với dữ liệu này, session này mỗi người/browser sẽ một khác nhau. Khi gửi request lên, server sẽ tự biết người nào của session nào, bạn chỉ cần kiểm tra session có đúng ko là được.

Ý tưởng là bạn cho người dùng đăng nhập trước, lưu session lại, khi người dùng post data thì kiểm tra endpoint của người đó có trùng với thông tin trên server không, nếu trùng thì thực hiện transaction/…

(Để tìm hiểu về kỹ hơn session thì bạn phải đào sâu xuống tầng dưới cách thức server làm việc, xử lí endpoint của sender, HEADER của HTTP, data/message qua lại giữa 2 bên, còn lại nếu làm web thì mình khuyên cứ dùng 1 thư viện có sẵn là được rồi, mất công đào sâu rách việc)

Thuc Nguyen Tan viết 14:14 ngày 01/10/2018

thk you thk youthk youthk youthk youthk youthk youthk you

Vô Thin viết 14:13 ngày 01/10/2018

Chả hiểu được chủ topic đang muốn nói gì luôn.

Lập trình dùng JavaScript cho cả server-side lẫn client-side luôn mà không tìm hiểu qua về thế nào là server-side và client-side tách biệt trong các ứng dụng web sơ khai để hiểu cách thức nó làm việc hay sao nhỉ? Mềnh hem hiểu được chỗ này.

Nếu cài đặt đúng CRUD thì làm gì có chuyện user này delete được bài của user khác nếu họ không có quyền (tức không phải là admin hay mod) chứ?

Luôn luôn phải thực hiện kiểm tra tất cả dữ liệu từ người dùng ở server-side, cho dù ở client-side có những trò hay ho gì đó để bớt sức tải cho server thì việc kiểm tra lại trên server là bắt buộc để biết user đó là ai, có quyền làm điều gì. Nếu không có các bước kiểm tra kỹ, sẽ có ngày người ta drop luôn cả database. Nếu chủ topic cảm thấy sợ hãi với những thao tác về CSDL thì dùng file .txt để lưu, file lưu/ xoá/ sửa và đọc là độc lập nhau, nhỡ kẻ phá hoại tự nâng quyền lên được thì cũng chỉ giới hạn trong thao tác nào đó thôi, khó mà tai hại kiểu SQL Injection. Nếu vẫn còn sợ, cẩn thận hơn nữa là mọi thao tác đều được ghi nhật ký lại, backup file, trường hợp tồi tệ nhất sẽ thực hiện thao tác như Undo ở các phần mềm thường thấy, cho phép Undo một ngàn bước chẳng hạn

Việc kiểm tra trên server đương nhiên 100% phải check xem user có login chưa? Nếu login rồi, quyền của anh ta là gì? Cẩn thận hơn nữa là có nhật ký các lần đăng nhập, so sánh trình duyệt, hệ điều hành, nếu thấy khả nghi buộc xác thực hai lớp qua SMS như ngân hàng vậy. Nếu cài đặt được cơ chế login không dùng cookies thì sẽ an toàn hơn, khó làm giả nếu người ta không phát hiện được lỗ hổng của giao thức xác thực đó, nhận biết được user là ai rồi thì nếu đúng bài người đó thì cho kèm theo nút sửa, khi sửa, bấm nút lưu thì phải kiểm tra lại lần nữa xem có đích xác “chính chủ” hay không trước khi commit vào cơ sở dữ liệu.

Dark.Hades viết 14:15 ngày 01/10/2018

Một lời khuyên là bạn nên sử dụng framework (không phải library) sau khi đã có căn bản về thứ mình đang học, xem họ làm thế nào, hoạt động ra sao, sâu đến đâu. Chứ tự lực cánh sinh từ số 0 thì không nên tí nào ở thời đại CNTT hiện nay.

Thuc Nguyen Tan viết 14:16 ngày 01/10/2018

ok, đợi tí, đang gửi mà phát hiện chỗ nhầm lẫn nên đang sửa tí

Thuc Nguyen Tan viết 14:13 ngày 01/10/2018

uh, mà thôi cái topic này đóng được rồi, cám ơn các bạn nhé:grinning:

Để mình mở chủ đề mới.

Bài liên quan
0