Tương đương biến phiên trong OWIN tự lưu trữ

Question

Tôi có một API web mẫu được lưu trữ trong quá trình OWIN (tự lưu trữ, không phải trong IIS). Tôi nhận được một mã thông báo JWT trong bộ điều khiển của mình và tôi muốn có thể truy xuất nó trong một phần khác của ứng dụng, một lớp thực hiện NserviceBus IMutateOutgoingTransportMessages. Trong ứng dụng web khác của tôi POC (được lưu trữ trong IIS), tôi đã sử dụng một biến phiên đơn giản và nó hoạt động tốt. Nhưng tôi muốn biết cách tốt nhất để làm điều đó trong môi trường tự lưu trữ OWIN mới của tôi là gì? Thuộc tính tĩnh trong lớp tĩnh?

Answer 1

Câu hỏi này thực sự rộng và khó trả lời mà không cần kiến ​​thức chi tiết về các nhu cầu cụ thể của bạn. Dưới đây là giải thích của tôi về vấn đề của bạn:

• Bạn đã ký mỗi yêu cầu, có lẽ lưu trữ các thẻ trong trình duyệt sessionStorage (hoặc thậm chí localStorage), nhưng điều này không đủ
• Bạn cần phải lấy token bên ngoài hoặc không liên quan đến bất kỳ chu kỳ theo yêu cầu (nếu không muốn nói, đây có lẽ là nơi bạn nên tìm kiếm câu trả lời)
• ứng dụng của bạn không cần phải được quốc tịch

Chỉ cần một tài sản tĩnh cho một chiếc thẻ trong một lớp tĩnh dĩ nhiên sẽ bắt đầu phá vỡ như s oon khi có nhiều hơn một yêu cầu truy cập vào ứng dụng cùng một lúc. Việc triển khai một lớp duy trì danh sách các mã thông báo có thể là một giải pháp, mặc dù tôi không thể cho biết bạn nên sử dụng khóa nào để nhận dạng từng mã thông báo. Chi tiết giao diện sẽ khác nhau tùy thuộc vào những thứ như nếu bạn cần truy xuất mã thông báo nhiều lần.

Vấn đề an toàn chủ đề sẽ áp dụng cho tất cả việc xử lý và triển khai lớp như vậy. Sử dụng Immutable Collections và thực hành lập trình chức năng làm nguồn cảm hứng có thể hữu ích.

Nếu thẻ kéo dài đặt ra vấn đề (và có thể từ quan điểm bảo mật, nếu không có gì khác), bạn cần tìm ra cách đảm bảo rằng mã thông báo không vượt quá sự chào đón của chúng, ngay cả khi chu kỳ là vì lý do nào đó chưa hoàn thành.

Xem cách bạn sử dụng Session làm giải pháp trong POC, tôi giả sử bạn muốn có hành vi tương tự và một người dùng không được phép mang hai thẻ vào cùng một lúc. Bạn có thể lưu trữ các mã thông báo i một cơ sở dữ liệu, hoặc thậm chí trong hệ thống tệp cục bộ, giúp bảo trì và hợp lệ hóa một vấn đề riêng biệt với nhau.

Có các triển khai chức năng giống như bộ nhớ cache đã có sẵn cho các ứng dụng tự lưu trữ OWIN và có thể một trong số đó sẽ là lối tắt để tự thực hiện mọi thứ.

Nếu thực tế mã thông báo này là lý do duy nhất để giới thiệu trạng thái trong ứng dụng của bạn, thì giải pháp tốt nhất IMHO sẽ là suy nghĩ lại kiến ​​trúc của bạn để ứng dụng có thể giữ trạng thái không trạng thái.

Answer 2

Tôi đang đối mặt với tình huống khó xử tương tự trên máy chủ mà tôi hiện đang phát triển cho khách hàng. Vấn đề của tôi là máy chủ phải thực hiện cuộc gọi (và giữ lại một kết nối trực tiếp) với một DLL đa luồng kế thừa, (còn gọi là SDK).

Tôi đã cố gắng để làm việc này trên IIS với dự án API Web thông thường. Thất bại nặng nề kể từ khi IIS tái tạo các luồng khi nó xác định rằng một chuỗi sẽ bị lừa đảo ... phù thủy là những gì mà luồng của SDK trông giống như trong phối cảnh đó. Ngoài ra, SDK phải có khả năng gọi lại trên trình gọi (ứng dụng khách đơn) và cho điều này tôi đang sử dụng SignalR.

Sau đó, tôi đã thử một hệ thống nhiều phần (trang đơn + api web trên dịch vụ IIS + WCF để tích hợp SDK).Nhưng đó là một cơn ác mộng thực sự để quản lý vì giao tiếp không đồng bộ 2 chiều phải xảy ra giữa tất cả các ứng dụng. Một lần nữa: thất bại.

Vì vậy, tôi hoàn nguyên về một dịch vụ OWIN + WebAPI được lưu trữ trong ứng dụng bảng điều khiển (hiện tại). Vấn đề của tôi là một số cuộc gọi kéo dài và được xử lý trong một chuỗi công nhân. Tôi quản lý để vượt qua id khách hàng SignalR trong mỗi cuộc gọi ajax thông qua các tiêu đề. Tôi có thể trích xuất id khi trong bộ điều khiển api web. Nhưng khi nhiệm vụ không đồng bộ, tôi cần lấy id (thông qua dịch vụ được Unity tiêm) từ lớp quản lý tác vụ không đồng bộ. Đây là vấn đề của tôi tương tự như của bạn. Trong IIS lưu trữ các ứng dụng, chúng tôi có HttpContext. Nó được contextualized trên mỗi cuộc gọi khách hàng, và sau bất kỳ thay đổi chủ đề trong các đường ống ... Nhưng không phải trong tự lưu trữ OWIN WCF ứng dụng ...

Tôi đang xem xét Thread Thread Storage, CallContext ... và các phương tiện khác theo dõi thông tin người gọi ban đầu trong suốt vòng đời của cuộc gọi không đồng bộ. Tôi đã đọc về đường ống OWIN, tôi có thể nắm bắt thông tin trong một phần mềm trung gian OWIN ... nhưng làm thế nào để giữ an toàn thông tin đó để sử dụng trong các dịch vụ được tiêm? Tôi vẫn đang tìm kiếm câu trả lời ...

Tôi đã tự hỏi liệu bạn có tìm thấy giải pháp cho vấn đề khá thú vị này không?

Tôi thích thêm vào chuỗi của bạn thay vì bắt đầu một chuỗi song song/câu hỏi SO khác.