Web服務訪問我有一個Flex應用程序，其收集用戶和帖子它交給我有一個後端服務器上運行的Web服務輸入的數據。 Flex應用程序不對用戶進行身份驗證（任何人都可以使用，無需設置帳戶），並使用HTTPS與Web服務通信。限制到一個面向公衆的Flex應用程序
沒有到位，以防止某些畸形請求XML防火牆，DoS攻擊等與web服務驗證從客戶端接收的所有數據。
如果我要簽署內容，那麼我可以使用XML防火牆來驗證簽名，但我認爲我嵌入客戶端中的任何證書類型數據都可以通過某些解編方式從Flex應用程序中提取出來。
我的問題是，是否有限制調用Web服務，只有那些從我Flex客戶端的方法嗎？我明白，用戶可能會輸入錯誤的信息，但我真的試圖阻止另一個客戶端或「機器人」。
如果我要介紹讓用戶帳戶充分利用基於會話的解決方案，那麼當我嘗試首先設置帳戶時（可能仍然需要在Flex應用程序）？
像TheBrain提到的，crossdomain.xml文件是你需要啓動，但這只是防止其他基於閃存的應用了。他關於隨機ID的想法也很好，但我可以看到實施起來相當複雜。您可以實現僅通過除flex應用程序之外的其他方式設置帳戶的用戶帳戶（推測更安全）。
另一種方式是讓應用程序和web服務側之間的共享密碼，加密對雙方使用某種鹽，雙方會知道的都該密碼。我的第一個直覺是想到一個基於時間的鹽。您可以將Flex應用程序中的時間戳與請求的其餘部分一起傳遞，然後將您的密碼和相同的時間戳連接在一起，並將其散列並一起傳遞。在Web服務中，當您收到請求時，您將使用相同的密碼（未通過請求以明文形式傳遞）和已傳遞的時間戳，並使用相同的算法對其進行哈希處理。然後比較。如果它們匹配，那麼它是一個認證請求。你甚至可以存儲密碼字典，並在一週中的每一天使用不同的密碼或類似的密碼。但是，只要你這樣做，確保你確定哈希密碼的兩種方法是相同的。這應該爲大多數應用提供足夠的安全性。讓我知道這是否需要澄清，或者我是否誤解了這個問題。
重新閱讀您的問題後，我看到您擔心反編譯。我的頭頂沒有答案。您可以將應用程序密碼存儲在應用程序之外並讀入，但這並不能解決人員反編譯能夠讀取該文件的問題。我會再想一想，看看我能不能提出一些防範措施。
您可以加入crossdomain.xml添加到您的服務器，以便那麼只有你的Flex應用程序可以訪問您的域名服務，...當你顯示網頁，你可以生成一些隨機ID，並給它的Flex應用程序作爲參數。所以當flex應用程序進行第一次服務調用時，該id應該在那裏。通過服務響應，生成另一個id並將其發送回flex以用於未來呼叫等。