Bui Trung Kien kienbt01359

#Tổng quan về Session

Session

Ứng dụng của bạn có 1 session cho mỗi người dùng để bạn có thể lưu một lượng data nhỏ mà sẽ tồn tại giữa nhiều request. Session chỉ khả dụng trong controller và view and có thể sử dụng một số cơ chế lưu trữ khác nhau.

ActionDispatch::Session::CookieStore - Lưu mọi thứ trên client.

ActionDispatch::Session::CacheStore - Lưu dữ liệu trong Rails cache.

ActionDispatch::Session::ActiveRecordStore - Lưu dữ liệu trong một cơ sở dữ liệu sử dụng Active Record.(yêu cầu gem activerecord-session_store).

ActionDispatch::Session::MemCacheStore - Lưu dữ liệu trong một memcached cluster (đây là một cách làm cũ; xem xét sử dụng CacheStore thay thế).
Tất cả session chứa một cookie để lưu một ID duy nhất cho mỗi session (bạn phải sử dụng một cookie, Rails sẽ không cho phép bạn truyền session ID trong URL vì thế rất là thiếu an toàn)

Với hầu hết các nơi chứa, ID này được sử dụng để tìm kiếm dữ liệu session trên server, ví dụ như trong bảng cơ sở dữ liệu. Có một excep

#Tìm hiểu về Authenticity Token trong Rails

Chuyện gì đã xảy ra?

Khi người dùng xem một form để tạo mới, cập nhật hay xóa một resource, ứng dụng Rails sẽ tạo một authenticity_token ngẫu nhiên, chứa cái authenticity_token này ở trong session, và đặt nó ở trong một hidden_field ở trong form.

<input name="authenticity_token" type="hidden" value="k9u7POignyF9RZiHT+C5kCwSoPPemDbAxd5va2CN4gY=">

Khi người dùng submit form, rails sẽ tìm kiếm authenticity_token, so sánh nó với cái mà được chứa trong session, và nếu chúng giống nhau thì request sẽ được cho phép tiếp tục. Xem thêm tại đây

Tại sao chuyện này xảy ra?

#Some curl sample commands in sample application ##Gett a cookie.

$ curl http://localhost:3000/users/new --cookie-jar "cookie.txt"

after this command, you will see a authenticity_token, please remember it.

##Sign Up

$ curl http://localhost:3000/users --request POST --data "authenticity_token=NCRWZ8JuQs6AFsQg9tw0TP26LyPAnG/ashI0iyMCF8w=" --cookie "cookie.txt" –data “user[name]=kien” --data "user[email][email protected]" --data "user[password]=foobar" --data "user[password_confirmation]=foobar"

#Routing Concerns [Rails 4 Countdown to 2013]

Bài viết này là 1 phần của series 31 bài viết về Rails 4 được công bố mỗi ngày trong 12/2012

Trong Rails config/routes.rb chịu trách nhiệm trong việc map URLs đến các actions của controller. Trong những năm qua, những sự bổ sung hữu ích được thêm vào để làm nhỏ file này xuống cho các developers, chúng ta có thể dừng việc lặp lại nay. Một ví dụ là phương thức điều hướng resources, cái mà map 4 routes đã được đặt tên tới 7 actions trong controller dựa trên phương thức request HTTP.

Với Rails 4, routing concerns đã được thêm vào router. Routing concerns cho phép bạn khai báo routes chung, mà có thể kết hợp vào trong các resources và routes khác.

##Ví dụ

#Edge Rails: PATCH là phương thức HTTP cơ bản mới dùng khi cập nhật dữ liệu. ##PATCH là gì? Phương thức HTTP PUT nghĩa là sự tạo mới hoặc thay thế resource tại URL nào đó được đưa ra. Ví dụ, nếu bạn upload 1 file lên S3 tại URL nào đó mà bạn muốn hoặc là tạo mới file hoặc là thay thế 1 file có sẵn (nếu có). Đó gọi là PUT.
Bây giờ hãy nói về 1 ứng dụng Web có 1 model tên là Invoice(hóa đơn) với một cờ trạng thái paid để tìm ra những hóa đơn nào đã đã được thanh toán. Làm thế nào để bạn thiết lập flag trong phương pháp RESTful? Gửi paid = 1 qua PUT tới /invoices/:id thì sẽ không phù hợp với ngữ nghĩa của HTTP, bởi vì những loại request này sẽ không được gửi 1 biểu diễn toàn diện của invoice để cho sự thay thế.

Với sự ràng buộc của các phương thức GET, PUT, POST, DELETE, câu trả lời muôn thuở đó là xác định cờ trạng thái paid của những invoice đã đưa ra để trở thành resource bởi chính nó(tức là định nghĩa cờ trạng thái paid thành một resource riêng, và là một phần của). Cho nên, bạ

##Một bài viết ngắn giới thiệu về REST Bạn có thể hoặc không thể biết được rằng về 1 phương pháp chính xác để thực hiện việc giao tiếp không đồng nhất giữa các ứng dụng với nhau(heterogeneous application-to-application communication): Trong khi xu hướng hiện nay là tập trung vào các dịch vụ Web dựa trên SOAP, WSDL và WS – Tuy nhiên, có một bộ phận nhỏ nhưng vô cùng quan trọng, khẳng định rằng có 1 phương pháp tốt hơn: đó là REST, viết tắt của cụm từ REpresentational State Transfer. Trong bài viết này, tôi sẽ cố gắng cung cấp một bài giới thiệu có tính chất thực tế về tích hợp ứng dung REST và RESTful HTTP. Tôi sẽ đi vào chi tiết hơn trong khi giải thích những khía cạnh mà theo kinh nghiệm của tôi, gây ra nhiều cuộc thảo luận nhất khi một người nào đó được tiếp xúc với phương pháp này lần đầu tiên. ##Nguyên tắc chính của REST Hầu hết những bài giới thiệu về REST bắt đầu với định nghĩa và kiến thức chung. Nhưng tôi sẽ không đề cập đến việc này trong 1 thời gian và đưa ra 1 định nghĩa đơn giản và thực tế: “RES

	` % Total % Received % Xferd Average Speed Time Time Time Current
	Dload Upload Total Spent Left Speed
	100 4323 <meta content="authenticity_token" name="csrf-param" />
	100 43<meta content="o8fq6RuChCMLvAitKGUVE3+OT90PBpVPzOYBo/mc7dc=" name="csrf-token" />
	23 0 0 142k 0 --:--:-- --:--:-- --:--:-- 145k`