[Discovery] Kinh nghiệm chọn mua DSLR cũ cho “lính mới”

Đối với phần đông người đam mê công nghệ thì một chiếc DSLR luôn là niềm mơ ước, tuy nhiên không phải ai cũng có đủ điều kiện để sở hữu một chiếc máy như ý muốn vì giá DSLR hiện tại vẫn còn ở mức cao so với thu nhập trung bình của người dân Việt Nam. Và chọn mua một chiếc máy ảnh DSLR hàng cũ là một lựa chọn khôn ngoan và ngay cả dân chơi ảnh cũng khuyến khích dùng hàng cũ để tiết kiệm chi phí.

Chọn mua máy ảnh cũ sẽ tiết kiệm cho bạn được một khoản lớn

Chọn mua máy ảnh cũ sẽ tiết kiệm cho bạn được một khoản lớn

Dưới đây sẽ là những kinh nghiệm mua máy ảnh DSLR cũ được tổng hợp từ nhiều nguồn.

1. Số shots

Với máy ảnh DSLR, số shots là yếu tố quyết định nhiều nhất đến giá trị của chiếc máy. Và khi đăng tin rao bán máy, bao giờ người bán cũng đính kèm số shots hiện tại của máy. Tuy nhiên số shots hoàn toàn có thể reset về 0 được, trước chỉ có ở máy Canon thì nay cũng đã rộ lên tin đồn ngay cả máy ảnh Nikon cũng có thể bị reset số shots. Tuổi thọ của màn trập máy ảnh DSLR phổ thông thường dao động trong khoảng từ 100.000 đến 150.000 shots (trên lý thuyết) áp dụng cho các máy phổ thông và bán chuyên. Còn các máy ảnh chuyên nghiệp như Canon 1D mark IV, Nikon D3 thường có tuổi thọ khoảng 400.000 shots (lý thuyết). Con số này có thể cao hơn hoặc ít hơn tùy thuộc vào điều kiện bảo quản và sử dụng của từng người. Lời khuyên cho bạn là nên mua những máy có số shots dưới 30.000 đối với máy ảnh phổ thông.

Để check số shots có thể dùng các phần mềm từ các hãng thứ ba, như EOSInfo cho máy Canon. Ngoài ra, các phần mềm đọc ảnh EXIF với các thông số siêu dữ liệu kèm ảnh cũng có thể cho biết số lần cửa trập đã sử dụng.

Số shots càng ít thì chứng tỏ máy càng mới

Số shots càng ít thì chứng tỏ máy càng mới

Số shots ít cũng đảm bảo một điều rằng sensor (cảm biến) của chiếc máy còn mới và tốt. Theo năm tháng, sensor sẽ kém dần đi về cảm nhận ánh sáng, màu sắc, thậm chí bị một số bệnh như dead pixel. Tuy nhiên cũng có một số trường hợp chủ cũ bảo quản không cẩn thận hoặc là máy reset shots nên dù số shots rất thấp nhưng trông máy đã rất xấu. Vì thế cần xem xét đến ngoại hình của máy nữa.

2. Ngoại hình

Ngoại hình đẹp chứng tỏ máy được giữ gìn và bảo quản tốt, có những máy số shots đã vượt quá cột mốc 100.000 nhưng ngoại hình vẫn còn rất đẹp. Với Nikon thì có một bệnh cố hữu với các dòng máy cũ là bong lớp cao su bọc ngoài do lớp keo dán không tốt, bệnh này có xảy ra cả với máy ảnh Canon nhưng ít hơn. Canon thì lại có phần cao su che các cổng kết nối nhanh bị lão hóa và đứt gãy sau 1 thời gian dài sử dụng.

Tiếp đến là kiểm tra toàn bộ các nút bấm và bánh răng xem có trục trặc gì trong quá trình sủ dụng không. Một số bánh răng bị trờn lẫy hoặc kẹt cứng rất khó quay nên hãy xoay đi xoay lại nhiều lần để kiểm tra thật kỹ. Thử các nút bấm xem độ phản hồi còn tốt hay không, đặc biệt là nút chụp, một số bị quá cứng hoặc quá nhạy có thể khiến bạn chụp 1 nhưng lại thành 2 tấm hình.

3. Các thành phần bên trong

Đầu tiên hãy gỡ miếng eye piece (miếng cao su ở trước ống ngắm) để kiểm tra hai con ốc phía dưới đã có dấu hiệu mở hay chưa. Nếu chưa thì chứng tỏ máy chưa qua sửa chữa và có thể tin tưởng được, hãy dò hỏi thêm người bán để thêm phần chắc chắn với vấn đề này.

Kế tiếp là ngó vào bên trong viewfinder (ống ngắm) và nhìn kỹ bên trong xem có bụi bẩn hay vết nứt vỡ nào không, nếu có vết nứt vỡ thì chứng tỏ máy đã từng bị va đập trong quá trình sử dụng trước đó. Phần tiếp theo mà bạn cần phải để ý đến là Hot Shoe – khu vực gắn flash mà máy nào cũng có. Nếu máy dùng nhiều với đèn flash thì khu vực này sẽ bị trầy xước và bong tróc nhiều.

Tiếp đến hãy ngó xuống ngàm gắn ống kính, màn trập và gương lật, dùng tay lật nhẹ gương lật lên và soi xem cảm biến có vấn đề gì như bụi hay mốc không. Chụp thử 1 tấm ảnh với nền đen kịt bằng cách không lắp lens, bịt chặt ngàm ống kính và đưa lên màn hình máy tính xem các điểm chết màu đỏ hoặc màu xanh, nếu có khoảng 2 3 điểm thì vẫn ổn còn nếu nhiều quá thì có lẽ bạn nên dừng việc khám chiếc máy này lại.

4. Màn hình, phụ kiện và bảo hành

Màn hình là nơi bạn nhìn vào nhiều nhất chỉ sau viewfinder, vì thế hãy kiểm tra nó thật kỹ, thường thì màn hình máy ảnh rất ít khi hỏng hay mắc bệnh, chỉ cần kiểm tra xem nó có vết bầm hay điểm chết hay không. Máy nào có cảm ứng thì kiểm tra luôn cả cảm ứng bằng các thao tác vuốt và chạm khắp màn hình.

Cuối cùng cúi xuống phần đế và xem số series sản xuất của máy, với máy Canon thì số Series hay bị mờ đi nếu hay dùng với grip hoặc tripod nhiều lần, Nikon thì không. Hãy hỏi người bán về phụ kiện đi kèm, nếu ít hơn hoặc không đúng miêu tả, hãy yêu cầu họ giảm giá cho đúng giá trị thực.

5. Lời khuyên cho bạn

Như mua mọi món đồ cũ khác, hãy mua bán tại nhà người bán hoặc ít nhất biết rõ địa chỉ nhà. Tuyệt đối không mua và test máy ở ngoài quán nước hay ngoài đường. Để quá trình kiểm tra diễn ra chính xác và thuận tiện thì hãy cố gắng test trong điều kiện đầy đủ ánh sáng. Và cho dù bạn có test tại chỗ kỹ đến mấy thì cũng vẫn bỏ sót một vài chỗ hoặc những lỗi không test tại chỗ được, nếu máy chất lượng tốt, người bán sẽ không ngại ngần cho phép bạn xin bao test vài ba hôm hay thậm chí 1 tuần vì thế hãy mạnh dạn đề nghị vì lợi ích của chính bạn.

[Discovery] Cuộc đời của 10 hacker mũ đen nổi tiếng thế giới

Trong số 10 hacker này, có người đã tự tử, có người phải ngồi tù nhưng cũng có người đang làm công việc có ích cho xã hội. Dù họ đã làm gì, có lẽ phải thừa nhận một điều rằng, họ thực sự giỏi.

10. Kevin Poulsen (Dark Dante)

Kevin Polsen là hacker mũ đen khét tiếng của thập kỷ 80 khi đột nhập vào đường dây điện thoại của đài phát thanh KIIS-FM của Los Angeles. Poulsen đã cố trốn tránh khi bị FBI săn lùng, nhưng cuối cùng đã bị bắt năm 1991.

Ông bị kết án bảy tội danh như lừa đảo qua máy tính, điện thoại, thư từ, tội rửa tiền, cản trở công lý, thu thập thông tin về các doanh nghiệp bí mật do FBI điều hành. Kevin Poulsen đã bị kết án 51 tháng tù giam (4 năm và 3 tháng), mức án nặng nhất cho một hacker thời điểm đó. Tuy nhiên, sau đó Poulsen đã trở thành nhà báo và hiện là biên tập viên của trang Wired News. Hầu hết các bài viết đáng chú ý của Poulsen là về quá trình điều tra 744 tội phạm tình dục trên MySpace.

9. Albert Gonzalez

Albert Gonzalez bị cáo buộc chủ mưu vụ trộm ATM và thẻ tín dụng lớn nhất trong lịch sử. Từ năm 2005-2007, ông và nhóm tội phạm ảo đã bán hơn 170 triệu thẻ và số thẻ ATM. Nhóm của Gonzalez đã sử dụng kỹ thuật SQL injection để tạo ra các backdoor (cửa sau) độc hại trên một số hệ thống máy tính các công ty để tấn công, nhằm ăn cắp dữ liệu từ mạng nội bộ công ty. Khi bị bắt, cơ quan chức năng đã thu giữ 1,6 triệu USD tiền mặt, bao gồm 1,1 triệu USD được tìm thấy trong túi nhựa giấu trong trống ba chân chôn ở sân sau nhà của bố mẹ ông. Năm 2010, Gonzalez bị kết án 20 năm trong nhà tù liên bang.

8. Vladimir Levin

Mọi thứ diễn ra gần giống như trong bộ phim về điệp viên James Bond: năm 1994, trong khi đang làm việc trên laptop từ căn hộ ở St Petersburg, Nga, Vladimir Levin đã chuyển 10 triệu USD từ tài khoản của các khách hàng Citibank vào tài khoản riêng của mình trên toàn thế giới. Tuy nhiên, sự nghiệp hacker của Levin rất ngắn ngủi, ông đã bị bắt, đi tù và nộp lại tất cả số tiền 10 triệu USD, chỉ còn thiếu 400.000 USD. Trong phiên xử Levin năm 1997 tại Mỹ, ông bị cho là đã điều phối cuộc tấn công các ngân hàng qua internet đầu tiên. Sự thật là Levin đã chuyển tiền của các khách hàng Citibank vào tài khoản của ông qua các số tài khoản và mã PIN bị đánh cắp. Levin đơn giản là đã can thiệp vào các cuộc gọi của khách hàng và ghi âm số tài khoản của họ.

7. Robert Tappan Morris

Ngày 2/11/1988, Robert Morris đã tung ra một con sâu máy tính và nó lây lan đến 1/10 mạng internet, khiến trên 6.000 hệ thống máy tính bị nhiễm. Cảnh sát không mất nhiều thời gian theo dõi hacker này. Một phần do nhu cầu “chém gió” của nhiều hacker trẻ, Morris đã phạm lỗi, chat về con sâu này nhiều tháng trước khi phát hành. Vụ việc đã gây thiệt hại 15 triệu USD.

Morris là một trong những người đầu tiên bị xét xử và bị kết án theo Luật gian lận máy tính, nhưng chỉ bị phạt phục vụ cộng đồng và phạt tiền. Tình tiết giảm nhẹ là con sâu của Morris không phá hủy nội dung dữ liệu của các máy tính bị ảnh hưởng. Hiện nay, Morris đang làm việc trong khoa Khoa học máy tính và kỹ thuật điện của Viện Công nghệ Massachusetts (MIT).

6. Michael Calce (MafiaBoy)

Tháng 2/2000, Michael Calce đã tung ra một loạt tấn công từ chối dịch vụ vào các website thương mại lớn, bao gồm cả Yahoo, Amazon.com, Dell, eBay, và CNN. Ông đã tấn công vào Yahoo khi Yahoo còn là công cụ tìm kiếm hàng đầu và làm tê liệt nó trong khoảng một giờ. Giống như nhiều tin tặc khác, Calce tấn công các website chủ yếu vì sự tự hào và nhằm thiết lập danh tiếng, sự thống trị cho bản thân và nhóm hacker của mình. Năm 2001, tòa án ở Montreal đã kết án Calce 8 tháng tù treo, một năm quản thúc, bị hạn chế sử dụng Internet, và bị phạt một khoản tiền nhỏ.

5. David Smith

Smith nổi tiếng vì là tác giả của virus e-mail Melissa. Smith khẳng định ông không hề có ý định để virus Melissa gây ra thiệt hại, tuy nhiên phương thức lây nhiễm của Melissa (mỗi máy tính bị lây nhiễm lại gửi đi vô số email độc hại) đã khiến các hệ thống máy tính và máy chủ trên toàn thế giới bị quá tải. Virus Melissa ẩn nấp trong một tệp tin có chứa mật khẩu của 80 website khiêu dâm nổi tiếng. Tên Melissa bắt nguồn từ một vũ công mà Smith gặp trong một chuyến đi ở Florida. Mặc dù có hơn 60.000 virus email được phát hiện, Smith là người duy nhất phải ngồi tù tại Mỹ vì “thả” ra một con virus.

4. Adrian Lamo

Có biệt danh là “hacker vô gia cư”, Adrian Lamo đã dùng các quán cà phê internet, thư viện để hành động. Lamo nổi tiếng vì đã đột nhập vào một loạt các mạng máy tính nổi tiếng, trong đó có New York Times, Microsoft, Yahoo, và MCI WorldCom. Năm 2002, ông lại gây ra vụ đột nhập vào cơ sở dữ liệu nội bộ của New York Times. New York Times đệ đơn khiếu nại, và lệnh bắt giữ Lamo được ban hành sau một cuộc điều tra kéo dài 15 tháng của các công tố viên liên bang New York.

Sau nhiều ngày lẩn trốn, cuối cùng Lamo đầu hàng và được dẫn đến FBI. Lamo phải trả khoảng 65.000 USD bồi thường thiệt hại và bị kết án sáu tháng quản thúc tại nhà cha mẹ, cộng thêm hai năm quản chế. Lamo hiện là nhà phân tích các mối đe dọa và cống hiện toàn bộ thời gian và kỹ năng của mình cho một tổ chức phi lợi nhuận có trụ sở ở Sacramento.

3.George Hotz

George Hotz sẽ mãi mãi gắn với vụ tấn công PlayStation hồi tháng 4/2011. Là một trong những hacker đầu tiên bẻ khóa Sony PlayStation 3, Hotz rơi vào cuộc chiến pháp lý liên miên với Sony – mọi thứ còn tệ hơn nữa do Hotz phát hành công khai phương thức bẻ khóa của mình.

Nhóm hacker Anonymous đã tấn công mạng lưới PlayStaion của Sony và đánh cắp thông tin cá nhân của khoảng 77 triệu người dùng. Tuy nhiên, Hotz phủ nhận mọi trách nhiệm về vụ tấn công và tuyên bố: “Bẻ khóa bảo mật trên các thiết bị thực sự rất thú vị, nhưng tấn công vào máy chủ của một ai đó và ăn cắp cơ sở dữ liệu thông tin người dùng chẳng thú vị và đáng nể tí nào”.

2. Jonathan James (c0mrade)

Jonathan James, hacker mũ đen 16 tuổi, trở thành trẻ vị thành niên đầu tiên bị bỏ tù tại Mỹ. James mang tai tiếng này sau khi thực hiện một loạt các vụ xâm nhập thành công vào nhiều hệ thống. Ở tuổi 15, James đã hack vào hệ thống chính phủ cao cấp như NASA và Bộ Quốc phòng. James còn bị cho là đã đánh cắp phần mềm trị giá hơn 1,7 triệu USD. Cậu bé cũng tấn công vào Cơ quan giảm nhẹ các mối đe dọa quốc phòng (DTRA) và ngăn chặn hơn 3.000 thông điệp tối mật đến và đi của các nhân viên DTRA, thu thập nhiều tên người dùng và mật khẩu.

Ngày 18/5/2008, ở tuổi 25, James đã tự tử bằng một khẩu súng. Những lời trong bức thư tuyệt mệnh của James đã cung cấp một cái nhìn sâu sắc vào về một cậu bé trẻ tuổi, tài năng, nhưng lại nghĩ rằng mình sẽ là một vật tế thần và đã đổ lỗi cho tội phạm mạng. Bức thư có đoạn viết: “Tôi không có niềm tin vào hệ thống công lý. Có lẽ hành động của tôi ngày hôm nay, và bức thư này, sẽ gửi một thông điệp mạnh mẽ cho công chúng. Dù sao chăng nữa, tôi đã không kiểm soát được tình trạng, và đây là cách duy nhất để tôi lấy lại sự kiểm soát của  mình”.

1. Gary McKinnon

Năm 2002, một thông báo kỳ lạ xuất hiện trên màn hình máy tính của quân đội Mỹ: “Hệ thống an ninh của quân đội Mỹ quá vớ vẩn. Tôi là Solo. Tôi sẽ tiếp tục phá hoại ở mức cao nhất”. Sau đó, bức thư được xác định là của Gary McKinnon, một người làm nghề quản trị hệ thống gốc Scotland.

McKinnon bị hội chứng Asperger, một chứng bệnh tự kỷ nghiêm trọng nhất. Các triệu chứng của hội chứng Asperger rất phù hợp với các hành động của Gary: đó là rất thông minh và có hiểu biết đặc biệt về các hệ thống phức tạp. Mặc dù chứng bệnh này khiến bệnh nhan gặp khó khăn trong một số giao tiếp xã hội, nhưng họ lại có xu hướng là thiên tài trong một lĩnh vực nào đó. Và đối với Gary, đó là máy tính.

Gary bị cáo buộc đã thực hiện vụ tấn công lớn nhất vào mạng máy tính chính phủ – bao gồm cả quân đội, không quân, hải quân và hệ thống NASA. Tòa án khuyến cáo rằng Gary phải đối mặt với các tội danh truy cập trái phép vào 97 máy tính, gây thiệt hại tổng cộng 700.000 USD.

Theo Technotification/Diễn đàn đầu tư

[Discovery] 10 thông tin thú vị xoay quanh ngày lễ hội Halloween

banner_halloween.

Thế giới lại chuẩn bị đón thêm một ngày hội Halloween nữa, ngày hội của bí đỏ, hóa trang và những trò đùa vui ma quái,… Ngày nay, lễ hội này đang dần trở nên phổ biến tại nhiều nước trên thế giới và tất nhiên là bao gồm cả Việt Nam. Nhiều ý kiến còn cho rằng đây là trong năm có 2 ngày lễ dành cho trẻ em là Giáng Sinh và Halloween, với đầy ắp những trò chơi, bánh kẹo và chocolate. Bài viết này sẽ điểm qua 10 thông tin thú vị xoay quanh ngày lễ “rùng rợn” này nhé. Chúc các bạn có đêm Halloween vui vẻ.

1. Halloween bắt nguồn từ lễ hội thần lửa Samhain của người Celt cổ đại

nguon_goc_nguoi_celt.

Theo nhiều học giả, ngày lễ Halloween hiện nay được kế thừa từ ngày hội thần lửa Samhain của người Celt cổ đại từ 6000 năm trước. Ngày hội này còn được biết đến với tên gọi “All Hallowtide”, được tổ chức sau khi hoàn tất mùa vụ và đánh dấu thời điểm khởi đầu cho mùa đông. Đối với người Celt cổ đại, thời điểm cuối mùa hè, đầu mùa đông có ý nghĩa hết sức quan trọng đối với đời sống của họ. Vào khoảng thời gian này, các cánh đồng cỏ không còn khả năng chăn nuôi gia súc, người dân cũng không còn bận việc đồng án. Họ tập trung thành từng nhóm vào trong các ngôi nhà chung để cùng nhau kể chuyện cho nhau nghe và lên kế hoạch chuẩn bị đón năm mới.

Cũng vào thời điểm này, khi vụ mùa đã được thu hoạch hoàn tất, các cánh đồng sẽ trở nên hoang vụ. Người Celt cho rằng đây sẽ là lúc những nàng tiên đến và thổi phép màu lên các cánh đồng. Đồng thời, họ quan niệm thời điểm chuyển giao mùa cũng trùng với lúc cánh cổng giữa 2 thế giới được mở ra, các linh hồn sẽ trở về cánh đồng và đó không phải là nơi thích hợp dành cho con người lui tới. Lúc này, họ sẽ tổ chức lễ hội Samhain trong khoảng 3 ngày nhằm tôn vinh thần lửa, cám ơn sau một vụ mùa và hy vọng mùa đông chóng qua.

Người Celt tin rằng vào ngày 31/10, quy luật về thời gian và không gian sẽ ngừng lại, các linh hồn sẽ trở về thế gian để tìm kiếm thân xác để hồi sinh. Do đó vào ngày này, người dân thường dập tắt các đám lửa trong nhà của họ, khiến họ trở nên lạnh lẽo và hy vọng các linh hồn sẽ bỏ qua. Đồng thời, họ cũng có tục lệ ăn mặc các trang phục mô phỏng ma quỷ, diễu hành ồn ào quanh các khu phố để trấn an nỗi lo sợ các linh hồn.

2. Ngày 31/10 được chọn như thế nào?

Duc_Me.

Đến năm 835 sau Công nguyên, Giáo hội Công giáo La Mã chính thức đổi ngày Lễ kính Đức Mẹ hồn xác lên trời 1/11 thành ngày Lễ các thánh Nam Nữ thay vì ngày 13/5. Đây là một trong những ngày lễ trọng trong năm của người Công giáo và một bữa tiệc ăn mừng sẽ được tổ chức. Kể từ đó, ngày 1/11 được gọi là ngày “All Saints Day” (Ngày lễ các thánh) và ngày 31/10 có tên là “All Hallow Even” (Sự kiện thánh hóa). Sau đó tên gọi trở thành “All Hallow’s Eve”, rồi “Hallowe’en” và cuối cùng là “Halloween”. Tiếp theo sau ngày lễ Các thánh Nam Nữ sẽ là ngày Lễ Các Đẳng Linh Hồn nhằm hiệp thông cầu nguyện cho những người đang trong tình trạng thanh tẩy ở Luyện Ngục (theo quan niệm Công Giáo)

3. Trò chơi Trick Or Treat là một hình thức ăn xin thời cổ đại

trick_or_treat_2.

Trò chơi Trick Or Treat (Lừa hay Lộc) là một trò chơi truyền thống trong ngày Halloween. Khi đó, các em nhỏ trong các bộ trang phục hóa trang, cầm lồng đèn, ca hát và đi từ nhà này sang nhà khác để gõ cửa và nói “trick or treat”. Thường người nhà sẽ cho bọn trẻ kẹo, chocolate hoặc trái cây chuẩn bị sẵn.

Trò chơi này có nguồn gốc từ thời cổ đại và được thực hiện bởi những người hành khất. Vào những ngày lễ trong năm, họ thường hát những bài hát mừng cho các chủ nhà giàu có để nhận được của bố thí. Sau đó trong ngày lễ Halloween, họ thường ngụy trang hoặc mặc các trang phục làm từ rơm và đi xung quanh những ngôi làng để xin thực phẩm hoặc bánh kẹo. Dần dần thành một tục lệ, những cư dân thường chờ ở nhà trong đêm Halloween để đợi các nhân vật hóa trang đến gõ cửa nhà họ. Sau khi đã hoàn tất, toàn bộ cư dân gồm cả những người hóa trang sẽ cùng nhau diễu hành trên đường phố và tập trung ở quảng trường để cùng nhau chung vui.

Một hình thức ăn xin cổ đại khác là trong các ngày lễ hội như Phục Sinh, Lễ các Thánh Nam Nữ,… những người hành khất sẽ đến gõ cửa từng nhà, xin thực phẩm và cầu nguyện cho những người đã qua đời trong gia đình đó.

4. Trick or Treat từng bị biến tướng thành hình thức phá hoại

Trick_or_treat.

Trick or Treat có thể là một trò chơi phổ biến trong ngày Halloween. Tuy nhiên trong quá khứ, nó từng bị biến tướng trở thành một dịp bạo lực và phá hoại. Khoảng 200 năm trước, trò chơi này đã là một phần của lễ Halloween, nhưng phần “trick” (chơi xấu) thường khá nguy hiểm và có khuynh hướng bạo lực. Đặc biệt là tại Mỹ, nhiều người quá khích thường mở cửa chuồng thả gà và gia súc, đặt bẫy trong nhà vệ sinh, phá hủy nhà kho hoặc thậm chí là bắn súng bên ngoài các tòa nhà. Họ cho rằng những trò phá hoại càng nguy hiểm thì trò chơi cành thành công.

Vào đầu thế kỷ 20, đặc biệt là khoảng thời gian giữa Chiến tranh thế giới, các hình thức phá hoại trong ngày Halloween đã bị chính quyền nhiều nơi cấm. Những hành vi đập phá, tiệc tùng quá khích hoặc các hành động phá hoại khác đều bị xử lý nghiêm khắc. Do đó, phong trào này đã dần đi vào dĩ vãng. Cuối cùng, trò chơi này chỉ dành cho trẻ em hoặc lứa tuổi thanh thiếu niên và được thực hiện một cách vui vẻ, an toàn như hiện nay.

5. Trò chơi Bobbing Apple cho bạn biết được vị hôn phu trong tương lai là ai?

bobbing-for-apples-rheann-earnest.

Cùng với trò Trick or Treat, một trò chơi có liên quan tới bói toán cũng rất phổ biến trong ngày Halloween là Bobbling Apple. Với trò chơi này, ggười ta cho rằng các linh hồn lang thang khắp thế giới trong ngày Halloween có thể biết được trong tương lai, những người nào sẽ trở thành vợ chồng của nhau.

Đây là trò chơi khá đơn giản, dễ bố trí, luật chơi đơn giản. Một nhóm các cô gái trẻ tuổi sẽ tập hợp thành nhóm, họ sẽ lấy những quả táo tươi, khoét một mẩu nhỏ và ăn mẩu táo đó. Trái táo sau khi khoét sẽ được ném vào chậu nước và nổi lên trên mặt. Cô gái đầu tiên có thể dùng miệng lấy được quả táo ra khỏi nước mà không chạm đến tay thì sẽ là người tiếp theo lập gia đình.

Sau đó, cô gái sẽ dùng chính quả táo đó để dự đoán ai sẽ là vị hôn thê của họ. Theo đó, cô ta sẽ gọt vỏ quả táo thành dải dài rồi ném vỏ táo đó qua vai vào thời khắc nửa đêm Halloween. Khi vỏ táo rơi xuống đất, nó sẽ có hình dạng chữ cái đầu tiên trong tên của người chồng trong tương lai.

6. Lịch sử bí ẩn và đen tối của quả bí Jack O’Lanterns

Jack-o-lantern-FR.

Quả bí Jack O’Lanterns được biết tới với một nguồn gốc đen tối và khá bí ẩn. Một truyền thuyết cổ xưa của người Ailen đã đề cập tới người đàn ông mang tên Stingy Jack. Một lần, Jack đã lừa quỷ satan uống rượu với ông. Sau khi uống say, Jack buộc phải thanh toán nhưng ông lại không muốn trả tiền. Do đó, Jack thuyết phục satan tự biến thành một đồng tiền để thanh toán tiền rượu. Jack nghĩ rằng nếu làm thế thì ông sẽ không phải thực sự tiêu tốn tiền của chính mình. Thật không may cho satan, Jack đã sớm lén đặt một cây Thánh Giá vào túi của ông. Ngay khi satan thi triển phép thuật biến thành đồng tiền, ông lấy nó bỏ vào túi và cây Thánh Giá đã vô hiệu hóa năng lực ma quỷ của satan nên hắn không thể nào biến dạng trở lại được nữa.

Jack hứa sẽ thả satan ra với 2 điều kiện: Đầu tiên, ma quỷ sẽ không bao giờ làm phiền Jack trong thời hạn ít nhất là 1 năm; thứ 2, khi Jack chết thì satan không được quyền bắt linh hồn của ông đi. Truyền thuyết kể rằng Jack đã tiếp tục lừa satan một lần nữa để ông có thể sống tự do thêm 10 năm sau đó. Dĩ nhiên, nhất bất quá tam, một lần thất tín thì vạn lần bất tin, Jack muốn tiếp tục lừa satan thêm nhưng không thể được nữa.

Nhiều năm sau đó, Jack qua đời và Thượng Đế đã không cho phép ông vào Thiên Đàng bởi những màn lừa đảo của ông. Mặt khác, quỷ dữ đã hứa sẽ không bao giờ bắt lấy linh hồn của Jack. Và kết quả là Jack buộc phải lang thang tại trần gian mãi mãi cùng với một hòn than cháy vĩnh viễn lấy từ hỏa ngục để có ánh sáng. Sau đó, Jack khắc một chiếc đèn lồng từ củ cải và bỏ hòn than vào trong đó để nó khỏi đốt cháy bàn tay của ông.

Kê từ đó, Jack trở thành Jack Of The Lantern (Jack của chiếc lồng đèn, sau này được gọi là Jack O’Lantern). Hàng đêm, Jack lang thang khắp nơi cùng chiếc lồng đèn để tìm kiếm thức ăn cho qua cơn đói. Đồng thời, Jack luôn kích động mọi người giết mình để ông có thể được chết. Tuy nhiên, điều đó đã không bao giờ xảy ra. Do đó, người ta thường khắc những khuôn mặt đáng sợ vào củ cải, củ cải đường hoặc khoai tây để hù dọa và xua đuổi Jack cùng quỷ dữ tránh xa khỏi nơi trú ngụ của họ. Câu chuyện trên được kể lại với các dị bản khác nhau nhưng có cốt truyện tương tự nhau.

7. Những chiếc lồng đèn ngày Halloween ban đầu được khắc từ củ cải và khoai tây mà không phải là bí đỏ

Jack-O-Lantern-Marvel_2.

Chiếc lồng đèn Jack O’Lantern được xem như một biểu tượng truyền thống của ngày Halloween. Trong suốt lịch sử, người ta đã dùng nhiều loại vật liệu để điêu khắc nên chiếc lồng đèn này. Tuy nhiên, bí ngô là một phiên bản xuất hiện gần đây, bắt đầu từ những người Ailen.

Như đã nói ở trên, vào thời điểm ban đầu người ta đã dùng củ cải và khoai tây để khắc thành những chiếc lồng đèn trong ngày Halloween. Nhưng nạn đói năm 1846 tại Ailen đã khiến củ cải và khoai tây vô cùng khan hiếm. Tất cả lương thực đều thiếu thốn thì làm sao người ta có thể lấy làm vật trang trí được! Lúc bấy giờ, người dân Ailen đã di cư tới Hoa Kỳ để tránh nạn đói và ảnh hưởng của suy thoái kinh tế. Khi đó, người ta đã bắt đầu dùng những quả bí ngô, có giá bán hết sức rẻ và được trồng rất nhiều tại vùng đất Bắc Mỹ trù phú này.Và kể từ đó, truyền thống đã dẫn thay đổi và tục khắc bí đỏ bắt đầu thịnh hành cho đến ngày nay.

8. Phù thủy và trăng tròn trong ngày Halloween

phu_thuy.

Phù thủy là 1 trong những nhân vật trung tâm và luôn có mặt trong các kỳ nghỉ lễ Halloween trong lịch sử. Khi cử hành ngày lễ Halloween, các phù thủy thường cọ xát một loại thuốc mỡ mà họ cho là linh thiêng, có nguồn gốc từ thảo dược vào da của họ. Loại chất này sẽ gây ra ảo giác, cho họ cảm giác như đang bay trên bầu trời. Người ta cho rằng những phù thủy giàu thường sẽ cưỡi ngựa, trong khi phù thủy nghèo thường sẽ cưỡi chổi hoặc một cái sào để bay trên cầu trời.

Thông thường, trong các bộ phim hoặc tiểu thuyết thường vẽ lên hình ảnh một phù thủy bay trên bầu trời, phía trên là mặt trăng tròn sáng tỏ đêm Halloween. Tuy nhiên, đây chỉ là hình ảnh đầy màu sắc nhằm tăng thêm tính nghệ thuật cho phim hay truyện. Theo ước tính của các nhà khoa học, lần trăng tròn trùng với đêm Halloween gần đây nhất là hồi năm 2001 và trước đó nữa là vào năm 1955. Và chúng ta phải đợi ít nhất là tới năm 2020 mới có được một dịp tương tự.

9. Kẹo và cơ hội kinh doanh

candy_Halloween.

Bạn có biết Halloween là 1 trong những cơ hội kinh doanh có tiềm năng nhất trong năm, chỉ xếp sau ngày lễ Giáng Sinh. Nhu cầu bánh kẹo, hoa quả những ngày cận Halloween tăng đột biến so với những tháng khác trong năm. Người ta ghi nhận tại Mỹ mỗi năm người ta tốn tổng cộng 2 tỷ đô la tiền kẹo để kỷ niệm ngày lễ này. Nếu tính riêng mảng tiêu thụ kẹo thì rõ ràng tại Mỹ, Halloween là ngày lễ “ngọt ngào” nhất trong năm, “ngọt” hơn cả Ngày lễ tình nhân của đôi lứa yêu nhau. Trên thực tế, lượng kẹo được bán nhiều nhất vào khoảng từ ngày 15/9 đến ngày 10/11 trong dịp Halloween.

10. Lễ Halloween cũng để lại những hậu quả đen tối cho thế giới thực

halloween_2.

Tuy ngày nay, đây chỉ là một ngày lễ kỷ niệm nhằm phục vụ mục đích vui vẻ là chính, nhưng Halloween cũng có tồn tại những tác động tiêu cực tại nhiều nơi trên thế giới. Nguyên nhân chủ yếu là do đêm Halloween, trẻ em được cho phép đi lang thang khắp nơi và không chịu sự kiểm soát của người lớn nên chúng có thể lâm vào những tình huống nguy hiểm.

Theo các thống kê, tỷ lệ trẻ em bị tai nạn giao thông trong đêm Halloween tăng lên gần gấp đôi so với những ngày khác trong năm. Đó cũng chỉ là 1 trong số những mối nguy hiểm tiềm tàng mà việc vui chơi thiếu kiểm soát có thể gây ra cho con người.

Cuối cùng, chúng ta đã điểm qua 10 thông tin thú vị về ngày lễ hội đáng sợ nhưng vui vẻ Halloween. Thời khắc lễ hội Halloween cũng sắp đến gần, chúc các bạn có một đêm Halloween vui vẻ và an toàn. Bạn nào có hình ảnh hóa trang hoặc bày trí, tham gia lễ hội này thì cũng có thể post xuống bên dưới để mọi người cùng chung vui nhé. Chúc sợ ma!

Tham khảo Wiki (1), (2), TC, BI, Cityroom, CWC

[Discovery] Bạn có thể thấy bạch cầu di chuyển trong mắt khi nhìn lên trời

mat.
Bạn đã bao giờ nhìn lên bầu trời xanh thật là lâu, cho tới khi thấy được những đốm màu trắng xanh di chuyển loạn xạ trước mắt không? Mình thì hay ngắm trời mây nên thường xuyên thấy hiện tượng đó, mình cứ nghĩ là do hoa mắt, nhưng thật không ngờ đó chính là các bạch cầu của mình đang di chuyển, và mình có thể nhìn thấy bạch cầu mà không cần kính hiển vi, mời bạn đọc bài dưới đây sẽ giải thích hiện tượng lý thú này.

Bạch cầu chỉ chiếm tỉ lệ khoảng 1% trong máu của bạn (nếu số lượng bạch cầu tăng cao tức là bạn đang bị nhiễm trùng). Hồng cầu di chuyển trong mạch máu theo từng nhóm, tuy nhiên trong các mạch máu rất nhỏ của mắt, các tế bào máu chỉ có thể di chuyển từng tế bào một, các tế bào hồng cầu hấp thu ánh sáng xanh do đó ta không thấy được nó, còn các tế bào bạch cầu thì không hấp thu ánh sáng, vì vậy ánh sáng chiếu xuyên qua nó.

Hệ thống mạch máu li ti nuôi dưỡng cho các tế bào cảm quang sẽ nhận được hồng cầu và bạch cầu, khi ta nhìn lên bầu trời xanh, hồng cầu sẽ che ánh sáng xanh, tuy nhiên ta sẽ không thấy trời tối thui do mắt ta sẽ điều chỉnh. Khi 1% bạch cầu di chuyển từng tế bào trong mạch máu, ánh sáng sẽ xuyên qua bạch cầu và đến các tế bào cảm quang, võng mạc gởi tín hiệu đến não để tăng tín hiệu sáng, lúc này ta sẽ thấy những đốm trắng xanh di chuyển trên bầu trời.
mat nguoi.

Hiện tượng lý thú này được nhiều nhà khoa học để ý nghiên cứu, và họ không dùng cách nghiên cứu mắt người, vì mắt người khi tham gia thực nghiệm thường không thấy được các đốm xanh trên trời.

Đầu tiên, các nhà khoa học tìm những mô cơ mỏng để chiếu ánh sáng xuyên qua. Lúc đầu họ dùng cánh của con dơi và mô tinh hoàn chuột, khi chiếu sáng qua các mô này, họ thấy được các đốm sáng duy chuyển trong mạch máu, sau đó bằng việc ghi chú tầng suất di chuyển, hướng di chuyển, kích thước điểm sáng, qua nhiều thực nghiệm, họ có kết luận rằng hiện tượng đốm sáng khi nhìn lên trời xanh là do bạch cầu.

Bạn dễ dàng nhìn thấy các đốm sáng này khi nhìn lên bầu trời xanh ít mây, nhưng đừng nhìn vào mặt trời vì sẽ hại mắt, bạn chỉ cần nhìn 1 lúc sẽ thấy được các đốm màu trắng xanh di chuyển, bạn sẽ nhận ra được vì chúng hầu như có cùng kích thước và chỉ di chuyển cùng một hướng, đó là hướng mạch máu của bạn

Theo IOVS.ORG, Hình GiangMU

[Dev Tip] Token Based Authentication using ASP.NET Web API 2, Owin, and Identity

Last week I was looking at the top viewed posts on my blog and I noticed that visitors are interested in the authentication part of ASP.NET Web API, CORS Support, and how to authenticate users in single page applications built with AngularJS using token based approach.

So I decided to compile mini tutorial of three five posts which covers and connects those topics. In this tutorial we’ll build SPA using AngularJS for the front-end, and ASP.NET Web API 2, Owin middleware, and ASP.NET Identity for the back-end.


The demo application can be accessed on (http://ngAuthenticationWeb.azurewebsites.net). The back-end API can be accessed on (http://ngAuthenticationAPI.azurewebsites.net/) and both are hosted on Microsoft Azure, for learning purposes feel free to integrate and play with the back-end API with your front-end application. The API supports CORS and accepts HTTP calls from any origin. You can check the source code for this tutorial on Github.

AngularJS Authentication

Token Based Authentication

As I stated before we’ll use token based approach to implement authentication between the front-end application and the back-end API, as we all know the common and old way to implement authentication is the cookie-based approach were the cookie is sent with each request from the client to the server, and on the server it is used to identify the authenticated user.

With the evolution of front-end frameworks and the huge change on how we build web applications nowadays the preferred approach to authenticate users is to use signed token as this token sent to the server with each request, some of the benefits for using this approach are:

  • Scalability of Servers: The token sent to the server is self contained which holds all the user information needed for authentication, so adding more servers to your web farm is an easy task, there is no dependent on shared session stores.
  • Loosely Coupling: Your front-end application is not coupled with specific authentication mechanism, the token is generated from the server and your API is built in a way to understand this token and do the authentication.
  • Mobile Friendly: Cookies and browsers like each other, but storing cookies on native platforms (Android, iOS, Windows Phone) is not a trivial task, having standard way to authenticate users will simplify our life if we decided to consume the back-end API from native applications.

What we’ll build in this tutorial?

The front-end SPA will be built using HTML5, AngularJS, and Twitter Bootstrap. The back-end server will be built using ASP.NET Web API 2 on top of Owin middleware not directly on top of ASP.NET; the reason for doing so that we’ll configure the server to issue OAuth bearer token authentication using Owin middleware too, so setting up everything on the same pipeline is better approach. In addition to this we’ll use ASP.NET Identity system which is built on top of Owin middleware and we’ll use it to register new users and validate their credentials before generating the tokens.

As I mentioned before our back-end API should accept request coming from any origin, not only our front-end, so we’ll be enabling CORS (Cross Origin Resource Sharing) in Web API as well for the OAuth bearer token provider.

Use cases which will be covered in this application:

  • Allow users to signup (register) by providing username and password then store credentials in secure medium.
  • Prevent anonymous users from viewing secured data or secured pages (views).
  • Once the user is logged in successfully, the system should not ask for credentials or re-authentication for the next 24 hours 30 minutes because we are using refresh tokens.

So in this post we’ll cover step by step how to build the back-end API, and on the next post we’ll cover how we’ll build and integrate the SPA with the API.

Enough theories let’s get our hands dirty and start implementing the API!

Building the Back-End API

Step 1: Creating the Web API Project

In this tutorial I’m using Visual Studio 2013 and .Net framework 4.5, you can follow along using Visual Studio 2012 but you need to install Web Tools 2013.1 for VS 2012 by visiting this link.

Now create an empty solution and name it “AngularJSAuthentication” then add new ASP.NET Web application named “AngularJSAuthentication.API”, the selected template for project will be as the image below. Notice that the authentication is set to “No Authentication” taking into consideration that we’ll add this manually.

Web API Project Template

Step 2: Installing the needed NuGet Packages:

Now we need to install the NuGet packages which are needed to setup our Owin server and configure ASP.NET Web API to be hosted within an Owin server, so open NuGet Package Manger Console and type the below:

The  package “Microsoft.Owin.Host.SystemWeb” is used to enable our Owin server to run our API on IIS using ASP.NET request pipeline as eventually we’ll host this API on Microsoft Azure Websites which uses IIS.

Step 3: Add Owin “Startup” Class

Right click on your project then add new class named “Startup”. We’ll visit this class many times and modify it, for now it will contain the code below:

What we’ve implemented above is simple, this class will be fired once our server starts, notice the “assembly” attribute which states which class to fire on start-up. The “Configuration” method accepts parameter of type “IAppBuilder” this parameter will be supplied by the host at run-time. This “app” parameter is an interface which will be used to compose the application for our Owin server.

The “HttpConfiguration” object is used to configure API routes, so we’ll pass this object to method “Register” in “WebApiConfig” class.

Lastly, we’ll pass the “config” object to the extension method “UseWebApi” which will be responsible to wire up ASP.NET Web API to our Owin server pipeline.

Usually the class “WebApiConfig” exists with the templates we’ve selected, if it doesn’t exist then add it under the folder “App_Start”. Below is the code inside it:

Step 4: Delete Global.asax Class

No need to use this class and fire up the Application_Start event after we’ve configured our “Startup” class so feel free to delete it.

Step 5: Add the ASP.NET Identity System

After we’ve configured the Web API, it is time to add the needed NuGet packages to add support for registering and validating user credentials, so open package manager console and add the below NuGet packages:

The first package will add support for ASP.NET Identity Owin, and the second package will add support for using ASP.NET Identity with Entity Framework so we can save users to SQL Server database.

Now we need to add Database context class which will be responsible to communicate with our database, so add new class and name it “AuthContext” then paste the code snippet below:

As you can see this class inherits from “IdentityDbContext” class, you can think about this class as special version of the traditional “DbContext” Class, it will provide all of the Entity Framework code-first mapping and DbSet properties needed to manage the identity tables in SQL Server. You can read more about this class on Scott Allen Blog.

Now we want to add “UserModel” which contains the properties needed to be sent once we register a user, this model is POCO class with some data annotations attributes used for the sake of validating the registration payload request. So under “Models” folder add new class named “UserModel” and paste the code below:

Now we need to add new connection string named “AuthContext” in our Web.Config class, so open you web.config and add the below section:

Step 6: Add Repository class to support ASP.NET Identity System

Now we want to implement two methods needed in our application which they are: “RegisterUser” and “FindUser”, so add new class named “AuthRepository” and paste the code snippet below:

What we’ve implemented above is the following: we are depending on the “UserManager” that provides the domain logic for working with user information. The “UserManager” knows when to hash a password, how and when to validate a user, and how to manage claims. You can read more about ASP.NET Identity System.

Step 7: Add our “Account” Controller

Now it is the time to add our first Web API controller which will be used to register new users, so under file “Controllers” add Empty Web API 2 Controller named “AccountController” and paste the code below:

By looking at the “Register” method you will notice that we’ve configured the endpoint for this method to be “/api/account/register” so any user wants to register into our system must issue HTTP POST request to this URI and the pay load for this request will contain the JSON object as below:

Now you can run your application and issue HTTP POST request to your local URI: “http://localhost:port/api/account/register” or you can try the published API using this end point: http://ngauthenticationapi.azurewebsites.net/api/account/register if all went fine you will receive HTTP status code 200 and the database specified in connection string will be created automatically and the user will be inserted into table “dbo.AspNetUsers”.

Note: It is very important to send this POST request over HTTPS so the sensitive information get encrypted between the client and the server.

The “GetErrorResult” method is just a helper method which is used to validate the “UserModel” and return the correct HTTP status code if the input data is invalid.

Step 8: Add Secured Orders Controller

Now we want to add another controller to serve our Orders, we’ll assume that this controller will return orders only for Authenticated users, to keep things simple we’ll return static data. So add new controller named “OrdersController” under “Controllers” folder and paste the code below:

Notice how we added the “Authorize” attribute on the method “Get” so if you tried to issue HTTP GET request to the end point “http://localhost:port/api/orders” you will receive HTTP status code 401 unauthorized because the request you send till this moment doesn’t contain valid authorization header. You can check this using this end point: http://ngauthenticationapi.azurewebsites.net/api/orders

Step 9: Add support for OAuth Bearer Tokens Generation

Till this moment we didn’t configure our API to use OAuth authentication workflow, to do so open package manager console and install the following NuGet package:

After you install this package open file “Startup” again and call the new method named “ConfigureOAuth” as the first line inside the method “Configuration”, the implemntation for this method as below:

Here we’ve created new instance from class “OAuthAuthorizationServerOptions” and set its option as the below:

  • The path for generating tokens will be as :”http://localhost:port/token”. We’ll see how we will issue HTTP POST request to generate token in the next steps.
  • We’ve specified the expiry for token to be 24 hours, so if the user tried to use the same token for authentication after 24 hours from the issue time, his request will be rejected and HTTP status code 401 is returned.
  • We’ve specified the implementation on how to validate the credentials for users asking for tokens in custom class named “SimpleAuthorizationServerProvider”.

Now we passed this options to the extension method “UseOAuthAuthorizationServer” so we’ll add the authentication middleware to the pipeline.

Step 10: Implement the “SimpleAuthorizationServerProvider” class

Add new folder named “Providers” then add new class named “SimpleAuthorizationServerProvider”, paste the code snippet below:

As you notice this class inherits from class “OAuthAuthorizationServerProvider”, we’ve overridden two methods “ValidateClientAuthentication” and “GrantResourceOwnerCredentials”. The first method is responsible for validating the “Client”, in our case we have only one client so we’ll always return that its validated successfully.

The second method “GrantResourceOwnerCredentials” is responsible to validate the username and password sent to the authorization server’s token endpoint, so we’ll use the “AuthRepository” class we created earlier and call the method “FindUser” to check if the username and password are valid.

If the credentials are valid we’ll create “ClaimsIdentity” class and pass the authentication type to it, in our case “bearer token”, then we’ll add two claims (“sub”,”role”) and those will be included in the signed token. You can add different claims here but the token size will increase for sure.

Now generating the token happens behind the scenes when we call “context.Validated(identity)”.

To allow CORS on the token middleware provider we need to add the header “Access-Control-Allow-Origin” to Owin context, if you forget this, generating the token will fail when you try to call it from your browser. Not that this allows CORS for token middleware provider not for ASP.NET Web API which we’ll add on the next step.

Step 11: Allow CORS for ASP.NET Web API

First of all we need to install the following NuGet package manger, so open package manager console and type:

Now open class “Startup” again and add the highlighted line of code (line 8) to the method “Configuration” as the below:

Step 12: Testing the Back-end API

Assuming that you registered the username “Taiseer” with password “SuperPass” in the step below, we’ll use the same username to generate token, so to test this out open your favorite REST client application in order to issue HTTP requests to generate token for user “Taiseer”. For me I’ll be using PostMan.

Now we’ll issue a POST request to the endpoint http://ngauthenticationapi.azurewebsites.net/token the request will be as the image below:

OAuth Token Request

Notice that the content-type and payload type is “x-www-form-urlencoded” so the payload body will be on form (grant_type=password&username=”Taiseer”&password=”SuperPass”). If all is correct you’ll notice that we’ve received signed token on the response.

As well the “grant_type” Indicates the type of grant being presented in exchange for an access token, in our case it is password.

Now we want to use this token to request the secure data using the end point http://ngauthenticationapi.azurewebsites.net/api/orders so we’ll issue GET request to the end point and will pass the bearer token in the Authorization header, so for any secure end point we’ve to pass this bearer token along with each request to authenticate the user.

Note: that we are not transferring the username/password as the case of Basic authentication.

The GET request will be as the image below:

Token Get Secure Resource

If all is correct we’ll receive HTTP status 200 along with the secured data in the response body, if you try to change any character with signed token you directly receive HTTP status code 401 unauthorized.

Now our back-end API is ready to be consumed from any front end application or native mobile app.

Update (2014-08-11) Thanks for Attila Hajdrik for forking my repo and updating it to use MongoDb instead of Entity Framework, you can check it here.

You can check the demo application, play with the back-end API for learning purposes (http://ngauthenticationapi.azurewebsites.net), and check the source code on Github.

Ref: http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/

Note:

1) Get Token with Fiddler

make request =>response

2) Make get orders

Get orders

[Dev Tip] Secure a Web API with Individual Accounts and Local Login

In Visual Studio 2013, the Web API project template gives you three options for authentication:

  • Individual accounts. The app uses a membership database.
  • Organizational accounts. Users sign in with their Azure Active Directory, Office 365, or on-premise Active Directory credentials.
  • Windows authentication. This option is intended for Intranet applications, and uses the Windows Authentication IIS module.

For more details about these options, see Creating ASP.NET Web Projects in Visual Studio 2013.

Individual accounts provide two ways for a user to log in:

  • Local login. The user registers at the site, entering a username and password. The app stores the password hash in the membership database. When the user logs in, the ASP.NET Identity system verifies the password.
  • Social login. The user signs in with an external service, such as Facebook, Microsoft, or Google. The app still creates an entry for the user in the membership database, but does not store any credentials. The user authenticates by signing into the external service.

This article looks at the local login scenario. For both local and social login, Web API uses OAuth2 to authenticate requests. However, the credential flows are different for local and social login.

In this article, I’ll demonstrate a simple app that lets the user log in and send authenticated AJAX calls to a web API. You can download the sample code here. The readme describes how to create the sample from scratch in Visual Studio.

The sample app uses Knockout.js for data-binding and jQuery for sending AJAX requests. I’ll be focusing on the AJAX calls, so you don’t need to know Knockout.js for this article.

Along the way, I’ll describe:

  • What the app is doing on the client side.
  • What’s happening on the server.
  • The HTTP traffic in the middle.

First, we need to define some OAuth2 terminology.

  • Resource. Some piece of data that can be protected.
  • Resource server. The server that hosts the resource.
  • Resource owner. The entity that can grant permission to access a resource. (Typically the user.)
  • Client: The app that wants access to the resource. In this article, the client is a web browser.
  • Access token. A token that grants access to a resource.
  • Bearer token. A particular type of access token, with the property that anyone can use the token. In other words, a client doesn’t need a cryptographic key or other secret to use a bearer token. For that reason, bearer tokens should only be used over a HTTPS, and should have relatively short expiration times.
  • Authorization server. A server that gives out access tokens.

An application can act as both authorization server and resource server. The Web API project template follows this pattern.

Local Login Credential Flow

For local login, Web API uses the resource owner password flow defined in OAuth2.

  1. The user enters a name and password into the client.
  2. The client sends these credentials to the authorization server.
  3. The authorization server authenticates the credentials and returns an access token.
  4. To access a protected resource, the client includes the access token in the Authorization header of the HTTP request.

When you select Individual accounts in the Web API project template, the project includes an authorization server that validates user credentials and issues tokens. The following diagram shows the same credential flow in terms of Web API components.

In this scenario, Web API controllers act as resource servers. An authentication filter validates access tokens, and the[Authorize] attribute is used to protect a resource. When a controller or action has the [Authorize] attribute, all requests to that controller or action must be authenticated. Otherwise, authorization is denied, and Web API returns a 401 (Unauthorized) error.

The authorization server and the authentication filter both call into an OWIN middleware component that handles the details of OAuth2. I’ll describe the design in more detail later in this tutorial.

Sending an Unauthorized Request

To get started, run the app and click the Call API button. When the request completes, you should see an error message in the Result box. That’s because the request does not contain an access token, so the request is unauthorized.

The Call API button sends an AJAX request to ~/api/values, which invokes a Web API controller action. Here is the section of JavaScript code that sends the AJAX request. In the sample app, all of the JavaScript app code is located in the Scripts\app.js file.

// If we already have a bearer token, set the Authorization header.
var token = sessionStorage.getItem(tokenKey);
var headers = {};
if (token) {
    headers.Authorization = 'Bearer ' + token;
}

$.ajax({
    type: 'GET',
    url: 'api/values/1',
    headers: headers
}).done(function (data) {
    self.result(data);
}).fail(showError);

Until the user logs in, there is no bearer token, and therefore no Authorization header in the request. This causes the request to return a 401 error.

Here is the HTTP request. (I used Fiddler to capture the HTTP traffic.)

GET https://localhost:44305/api/values HTTP/1.1
Host: localhost:44305
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: */*
Accept-Language: en-US,en;q=0.5
X-Requested-With: XMLHttpRequest
Referer: https://localhost:44305/

HTTP response:

HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/8.0
WWW-Authenticate: Bearer
Date: Tue, 30 Sep 2014 21:54:43 GMT
Content-Length: 61

{"Message":"Authorization has been denied for this request."}

Notice that the response includes a Www-Authenticate header with the challenge set to Bearer. That indicates the server expects a bearer token.

Register a User

In the Register section of the app, enter an email and password, and click the Register button.

You don’t need to use a valid email address for this sample, but a real app would confirm the address. (See Create a secure ASP.NET MVC 5 web app with log in, email confirmation and password reset.) For the password, use something like “Password1!”, with an upper case letter, lower case letter, number, and non-alpha-numeric character. To keep the app simple, I left out client-side validation, so if there is a problem with the password format, you’ll get a 400 (Bad Request) error.

The Register button sends a POST request to ~/api/Account/Register/. The request body is a JSON object that holds the name and password. Here is the JavaScript code that sends the request:

var data = {
    Email: self.registerEmail(),
    Password: self.registerPassword(),
    ConfirmPassword: self.registerPassword2()
};

$.ajax({
    type: 'POST',
    url: '/api/Account/Register',
    contentType: 'application/json; charset=utf-8',
    data: JSON.stringify(data)
}).done(function (data) {
    self.result("Done!");
}).fail(showError);

HTTP request:

POST https://localhost:44305/api/Account/Register HTTP/1.1
Host: localhost:44305
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: */*
Content-Type: application/json; charset=utf-8
X-Requested-With: XMLHttpRequest
Referer: https://localhost:44305/
Content-Length: 84

{"Email":"alice@example.com","Password":"Password1!","ConfirmPassword":"Password1!"}

HTTP response:

HTTP/1.1 200 OK
Server: Microsoft-IIS/8.0
Date: Wed, 01 Oct 2014 00:57:58 GMT
Content-Length: 0

This request is handled by the AccountController class. Internally, AccountController uses ASP.NET Identity to manage the membership database.

If you run the app locally from Visual Studio, user accounts are stored in LocalDB, in the AspNetUsers table. To view the tables in Visual Studio, click the View menu, select Server Explorer, then expand Data Connections.

Get an Access Token

So far we have not done any OAuth, but now we’ll see the OAuth authorization server in action, when we request an access token. In the Log In area of the sample app, enter the email and password and click Log In.

The Log In button sends a request to the token endpoint. The body of the request contains the following form-url-encoded data:

  • grant_type: “password”
  • username: <the user’s email>
  • password: <password>

Here is the JavaScript code that sends the AJAX request:

var loginData = {
    grant_type: 'password',
    username: self.loginEmail(),
    password: self.loginPassword()
};

$.ajax({
    type: 'POST',
    url: '/Token',
    data: loginData
}).done(function (data) {
    self.user(data.userName);
    // Cache the access token in session storage.
    sessionStorage.setItem(tokenKey, data.access_token);
}).fail(showError);

If the request succeeds, the authorization server returns an access token in the response body. Notice that we store the token in session storage, to use later when sending requests to the API. Unlike some forms of authentication (such as cookie-based authentication), the browser will not automatically include the access token in subsequent requests. The application must do so explicitly. That’s a good thing, because it limits CSRF vulnerabilities.

HTTP request:

POST https://localhost:44305/Token HTTP/1.1
Host: localhost:44305
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: */*
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: https://localhost:44305/
Content-Length: 68

grant_type=password&username=alice%40example.com&password=Password1!

You can see that the request contains the user’s credentials. You must use HTTPS to provide transport layer security.

HTTP response:

HTTP/1.1 200 OK
Content-Length: 669
Content-Type: application/json;charset=UTF-8
Server: Microsoft-IIS/8.0
Date: Wed, 01 Oct 2014 01:22:36 GMT

{
  "access_token":"imSXTs2OqSrGWzsFQhIXziFCO3rF...",
  "token_type":"bearer",
  "expires_in":1209599,
  "userName":"alice@example.com",
  ".issued":"Wed, 01 Oct 2014 01:22:33 GMT",
  ".expires":"Wed, 15 Oct 2014 01:22:33 GMT"
}

For readability, I indented the JSON and truncated the access token, which is a quite long.

The access_token, token_type, and expires_in properties are defined by the OAuth2 spec. The other properties (userName, .issued, and .expires) are just for informational purposes. You can find the code that adds those additional properties in the TokenEndpoint method, in the /Providers/ApplicationOAuthProvider.cs file.

Send an Authenticated Request

Now that we have a bearer token, we can make an authenticated request to the API. This is done by setting the Authorization header in the request. Click the Call API button again to see this.

HTTP request:

GET https://localhost:44305/api/values/1 HTTP/1.1
Host: localhost:44305
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: */*
Authorization: Bearer imSXTs2OqSrGWzsFQhIXziFCO3rF...
X-Requested-With: XMLHttpRequest

HTTP response:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/8.0
Date: Wed, 01 Oct 2014 01:41:29 GMT
Content-Length: 27

"Hello, alice@example.com."

Log Out

Because the browser does not cache the credentials or the access token, logging out is simply a matter of “forgetting” the token, by removing it from session storage:

self.logout = function () {
    sessionStorage.removeItem(tokenKey)
}

Understanding the Individual Accounts Project Template

When you select Individual Accounts in the ASP.NET Web Application project template, the project includes:

  • An OAuth2 authorization server.
  • A Web API endpoint for managing user accounts
  • An EF model for storing user accounts.

Here are the main application classes that implement these features:

  • AccountController. Provides a Web API endpoint for managing user accounts. The Register action is the only one that we used in this tutorial. Other methods on the class support password reset, social logins, and other functionality.
  • ApplicationUser, defined in /Models/IdentityModels.cs. This class is the EF model for user accounts in the membership database.
  • ApplicationUserManager, defined in /App_Start/IdentityConfig.cs This class derives from UserManager and performs operations on user accounts, such as creating a new user, verifying passwords, and so forth, and automatically persists changes to the database.
  • ApplicationOAuthProvider. This object plugs into the OWIN middleware, and processes events raised by the middleware. It derives from OAuthAuthorizationServerProvider.

Configuring the Authorization Server

In StartupAuth.cs, the following code configures the OAuth2 authorization server.

PublicClientId = "self";
OAuthOptions = new OAuthAuthorizationServerOptions
{
    TokenEndpointPath = new PathString("/Token"),
    Provider = new ApplicationOAuthProvider(PublicClientId),
    AuthorizeEndpointPath = new PathString("/api/Account/ExternalLogin"),
    AccessTokenExpireTimeSpan = TimeSpan.FromDays(14),
    // Note: Remove the following line before you deploy to production:
    AllowInsecureHttp = true
};

// Enable the application to use bearer tokens to authenticate users
app.UseOAuthBearerTokens(OAuthOptions);

The TokenEndpointPath property is the URL path to the authorization server endpoint. That’s the URL that app uses to get the bearer tokens.

The Provider property specifies a provider that plugs into the OWIN middleware, and processes events raised by the middleware.

Here is the basic flow when the app wants to get a token:

  1. To get an access token, the app sends a request to ~/Token.
  2. The OAuth middleware calls GrantResourceOwnerCredentials on the provider.
  3. The provider calls the ApplicationUserManager to validate the credentials and create a claims identity.
  4. If that succeeds, the provider creates an authentication ticket, which is used to generate the token.

The OAuth middleware doesn’t know anything about the user accounts. The provider communicates between the middleware and ASP.NET Identity. For more information about implementing the authorization server, see OWIN OAuth 2.0 Authorization Server.

Configuring Web API to use Bearer Tokens

In the WebApiConfig.Register method, the following code sets up authentication for the Web API pipeline:

config.SuppressDefaultHostAuthentication();
config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType));

The HostAuthenticationFilter class enables authentication using bearer tokens.

The SuppressDefaultHostAuthentication method tells Web API to ignore any authentication that happens before the request reaches the Web API pipeline, either by IIS or by OWIN middleware. That way, we can restrict Web API to authenticate only using bearer tokens.

In particular, the MVC portion of your app might use forms authentication, which stores credentials in a cookie. Cookie-based authentication requires the use of anti-forgery tokens, to prevent CSRF attacks. That’s a problem for web APIs, because there is no convenient way for the web API to send the anti-forgery token to the client. (For more background on this issue, seePreventing CSRF Attacks in Web API.) Calling SuppressDefaultHostAuthentication ensures that Web API is not vulnerable to CSRF attacks from credentials stored in cookies.

When the client requests a protected resource, here is what happens in the Web API pipeline:

  1. The HostAuthentication filter calls the OAuth middleware to validate the token.
  2. The middleware converts the token into a claims identity.
  3. At this point, the request is authenticated but not authorized.
  4. The authorization filter examines the claims identity. If the claims authorize the user for that resource, the request is authorized. By default, the [Authorize] attribute will authorize any request that is authenticated. However, you can authorize by role or by other claims. For more information, see Authentication and Authorization in Web API.
  5. If the previous steps are successful, the controller returns the protected resource. Otherwise, the client receives a 401 (Unauthorized) error.

Additional Resources

[Technology] Các nhà nghiên cứu Hà Lan xác lập kỷ lục mới về tốc độ truyền dữ liệu: 255 Terabits/s

Tinhte_soi_cap_quang_7_loi_2.

Các nhà nghiên cứu tại Đại học công nghệ Eindhoven (TU/e), Hà Lan, tuyên bố đã phát triển thành công dạng cáp thế hệ mới với băng thông lớn gấp 21 lần so với chuẩn giao tiếp mạng hiện tại. Với dạng cáp nói trên, nhóm nghiên cứu đã lập kỷ lục mới với tốc độ truyền tải dữ liệu là 255 Terabits/s. Dạng cáp mới hứa hẹn sẽ giải quyết được vấn đề tắc nghẽn mạng cáp quang do nhu cầu sử dụng đang ngày càng tăng như hiện nay.

Ngày nay, mức tăng trưởng nhanh chóng của các dịch vụ Internet và sự ra đời của ngày càng nhiều các trung tâm dữ liệu, kéo theo nhu cầu sử dụng băng thông cũng tăng theo một cách đột biến. Để truyền được lượng dữ liệu lớn hơn bằng hệ thống cáp quang hiện tại, một lựa chọn được đề xuất là tăng cường độ tín hiệu để khắc phục những hao hụt vốn có trong quá trình truyền dữ liệu trên vật liệu sợi thủy tinh. Tuy nhiên, cách làm này vô tình tạo ra hiệu ứng quang học phi tuyến, khiến việc phục hồi thông tin sau quá trình truyền tải chỉ có thể được thực hiện trong một giới hạn nhất định.

Tinhte_soi_cap_quang_7_loi.
Dạng cáp mới với 7 loại lõi, mỗi lõi có thêm 2 chiều vuông góc, cho tốc độ truyền dữ liệu đạt 255 Terabits/s

Nhóm các nhà nghiên cứu tại TU/e, dẫn đầu bởi tiến sĩ Chigo Okonkwo và Rodrigo Amezcua Correa, đã chứng minh tiềm năng của một dạng cáp mới giúp tăng khả năng truyền tải dữ liệu và giảm thiểu ảnh hưởng khi tình huống tắc nghẽn xảy ra. Công trình nghiên cứu đã được công bố trên tạp chí Nature Photonics số ra mới đây.

Về cơ bản, dạng cáp mới bao gồm 7 lõi khác nhau thay vì chỉ có 1 lõi như trên thế hệ cáp quang hiện tại. Mỗi lõi đều có khả năng truyền dẫn ánh sáng. Chúng ta có thể hình dung dạng sợi mới như một con đường cao tốc với 7 làn đường khác nhau. Tuy nhiên, điểm đặc biệt là mỗi “làn đường” được bổ sung thêm 2 chiều vuông góc. Đồng thời các “làn đường phụ” cũng có khả năng truyền tải dữ liệu. Điều này cho phép “3 xe chở dữ liệu” có thể di chuyển trên cùng một “làn đường”. Kết quả cuối cùng, kỹ thuật này cho phép các nhà nghiên cứu có thể truyền được tổng cộng 255 Terabits dữ liệu mỗi giây, nhanh gấp 20 lần so với chuẩn hiện tại (4-8 Terabits/s). Con số này tương đương tốc độ khoảng 32Terabyte/s.

Tiến sĩ Chigo Okonkwo cho biết: “Dạng cáp mới có đường kính chưa tới 200 micromet nên sẽ không chiếm nhiều không gian như các hệ thống cáp trước đây. Tuy nhiên, tốc độ truyền tải dữ liệu của nó là thật sự đáng kinh ngạc. Mặt khác, đây chỉ là khởi đầu và khả năng trong tương lai, con số tốc độ có thể tăng lên tới hàng Petabits/s.” Đó cũng chính là mục tiêu chính trong chương trình nghiên cứu phát triển công nghệ truyền dữ liệu do Ủy ban liên minh châu Âu khởi xướng và dự kiến sẽ hoàn thành vào năm 2020. Đồng thời, loại cáp mới còn tạo tiền đề cho nhiều kỷ lục khác được xác lập trong tương lai nhằm giải quyết nhu cầu băng thông internet toàn cầu đang tăng trưởng cực kỳ nhanh chóng như hiện nay.

Tham khảo Extremetech, NP, STR