當前位置:首頁 » 網頁前端 » web提交數據後台拒絕
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

web提交數據後台拒絕

發布時間: 2022-04-23 04:52:18

① JSP+java模式的WEB應用,如果瀏覽器提交更新請求後,突然關閉,後台事務怎麼處理

應該是看提交的是不是一個完整的事務吧,如果是,那應該可以執行,如果不是,那就要回滾了吧~

② JavaWeb開發 網頁傳遞參數給後台程序

每個選項都可以放進一個標簽,比如<a href="javascript(0)" onclick="jump('xx')">AMD平台</a>,js中寫一個方法:function jump(obj){window.location.href="servlet/XXServlet?xx=obj"},然後再servlet裡面用request接收,處理後再返回某個頁面即可,js中跳轉的地址不一定是servlet,也可以是jsp,帶上參數傳過去再返回一個頁面就可以了。。。點擊後陰影效果的樣式即class也可當作參數傳過去,處理完後再把參數傳回本頁面即可。。。

③ web項目,數據後台驗證的相關問題求解

1、前台一般驗證的時候是驗證一下表單中輸入框的值是否輸入正常,包括不為空等等;如果是要驗證電話號碼、身份證一些有格式的驗證一般都是採用js正則表達式進行驗證,驗證通過傳入後台既可,不需要在後台驗證;後台驗證的東西一般是你需要在資料庫中進行增刪改查操作的東西,例如你驗證前台輸入的用戶名是否存在資料庫中就需要後台驗證。
2、方法有很多,一般後台採用ajax驗證後將你的驗證信息用json格式封裝返回頁面進行操作即可,前台可以用js,現在正在學的jquery-easyui中的validBox控制項驗證前台也很不錯,比較方便。框架驗證,好吧,我沒用過。

④ 我上傳了個網站,網站能打開,但是網站後台的鏈接顯示「403禁止訪問, 網站拒絕顯示此網頁 」不知什麼原因

可能是寫許可權受限制,網站全部上傳成功了嗎,或者資料庫綁定成功了嗎?

錯誤代碼:403.1
403.1錯誤是由於'執行'訪問被禁止而造成的,若試圖從目錄中執行 CGI、ISApI 或其他可執行程序,但該目錄不允許執行程序時便會出現此種錯誤。

錯誤代碼:403.2
403.2錯誤是由於'讀取'訪問被禁止而造成的。導致此錯誤是由於沒有可用的默認網頁並且沒有對目錄啟用目錄瀏覽,或者要顯示的 HTML 網頁所駐留的目錄僅標記為'可執行'或'腳本'許可權。

錯誤代碼:403.3
403.3錯誤是由於'寫入'訪問被禁止而造成的,當試圖將文件上載到目錄或在目錄中修改文件,但該目錄不允許'寫'訪問時就會出現此種錯誤。

錯誤代碼:403.4
403.4錯誤是由於要求SSL而造成的,您必須在要查看的網頁的地址中使用'https'。

錯誤代碼:403.5
403.5錯誤是由於要求使用 128 位加密演算法的 Web 瀏覽器而造成的,如果您的瀏覽器不支持128位加密演算法就會出現這個錯誤,您可以連接微軟網站進行瀏覽器升級。

錯誤代碼:403.6
403.6錯誤是由於Ip 地址被拒絕而造成的。如果伺服器中有不能訪問該站點的 Ip 地址列表,並且您使用的 Ip 地址在該列表中時您就會返回這條錯誤信息。

錯誤代碼:403.7
403.7錯誤是因為要求客戶證書,當需要訪問的資源要求瀏覽器擁有伺服器能夠識別的安全套接字層 (SSL) 客戶證書時會返回此種錯誤。

錯誤代碼:403.8
403.8錯誤是由於禁止站點訪問而造成的,若伺服器中有不能訪問該站點的 DNS 名稱列表,而您使用的 DNS 名稱在列表中時就會返回此種信息。請注意區別403.6與403.8錯誤。

錯誤代碼:403.9
403.9錯誤是由於連接的用戶過多而造成的,由於Web 伺服器很忙,因通訊量過多而無法處理請求時便會返回這條錯誤。

錯誤代碼:403.10
403.10錯誤是由於無效配置而導致的錯誤,當您試圖從目錄中執行 CGI、ISApI 或其他可執行程序,但該目錄不允許執行程序時便會返回這條錯誤。

錯誤代碼:403.11
403.11錯誤是由於密碼更改而導致無權查看頁面。

錯誤代碼:403.12
403.12錯誤是由於映射器拒絕訪問而造成的。若要查看的網頁要求使用有效的客戶證書,而您的客戶證書映射沒有許可權訪問該 Web 站點時就會返回映射器拒絕訪問的錯誤。

錯誤代碼:403.13
403.13錯誤是由於需要查看的網頁要求使用有效的客戶證書而使用的客戶證書已經被吊銷,或者無法確定證書是否已吊銷造成的。

錯誤代碼:403.15
403.15錯誤是由於客戶訪問許可過多而造成的,當伺服器超出其客戶訪問許可限制時會返回此條錯誤。

錯誤代碼:403.16
403.16錯誤是由於客戶證書不可信或者無效而造成的。

錯誤代碼:403.17
403.17錯誤是由於客戶證書已經到期或者尚未生效而造成的。

⑤ java web項目突然後台無法添加內容

redis連接異常了,看下jedis連接redis的遠程地址,埠是否正常

⑥ 新手求助,表單數據提交不到後台

建議看下你說的表單操作步驟:首先是你要收集信息,建一個表單大師賬號——點擊創建新表單——選擇想用的欄位——點擊發布——發送鏈接地址到群或者個人(或者發送表單二維碼)——別人填寫你發送的表單信息點擊提交——到自己表單大師賬戶管理後台——點擊查看你建你的那個表單的數據,就會看到提交的數據了。如果你只是提交表單者,不是對應表單的賬戶管理員是看不到後台數據提交信息的

⑦ java web項目在打開後向資料庫添加數據網頁顯示添加失敗請與管理員聯系

前端寫了失敗處理,就是彈對話框。

首先,你得查資料庫是不是真存進去了,因為有的前端做的假處理。然後排查

  1. 是不是前端JS傳值問題(比如寫錯什麼的)

  2. 還有可能性:如果前端傳值了,到後端被攔截。如果是被攔截 最有可能的是許可權的問題。因為可能後端做了許可權處理,許可權不足就會被攔截器攔截。

  3. 資料庫遠程連接的問題 那就搜相關排查 看埠,ping通那些

⑧ JAVA WEB 資料庫為後台 注冊效果不能成功

問的問題太大了,顯示「注冊失敗」,我猜的意思是,你做個注冊功能,在用servlet返回的時候在jsp
顯示「注冊失敗」。
我看了一下代碼,其實很簡單:你注冊是提交到RegisterServlet上面的,返回失敗是:

boolean flag =uo.add(user);
//4.
PrintWriter out = response.getWriter();
if(flag){
out.print("<h3>注冊成功,請登錄!</h3>");
}else{
out.print("<h3>注冊失敗,請重試!</h3>");
}
因此,就是你保存的時候uo.add(user)反回false:
//用戶注冊方法
public boolean add(User user){
int flag = 0;
sql = "insert into user_info values(?,?,?,?)";
try {
psmt = con.prepareStatement(sql);
psmt.setString(1,user.getName());
psmt.setString(2,user.getPassword());
psmt.setString(3,user.getPhone());
psmt.setString(4,user.getEmail());
flag = psmt.executeUpdate();
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return flag>0?true:false;
}
所以flag = psmt.executeUpdate();這個有問題,你再仔細看看

⑨ 磁碟滿了後web伺服器為什麼會拒絕請求

web伺服器請求需要寫入數據到磁碟中,磁碟滿了後了數據不能寫入。之所有拒絕了請求。

⑩ web攻擊有哪些怎麼防護

1、DoS和DDoS攻擊(DoS(Denial of Service),即拒絕服務,造成遠程伺服器拒絕服務的行為被稱為DoS攻擊。其目的是使計算機或網路無法提供正常的服務。最常見的DoS攻擊有計算機網路帶寬攻擊和連通性攻擊)
防範:(1) 反欺騙:對數據包的地址及埠的正確性進行驗證,同時進行反向探測。(2) 協議棧行為模式分析:每個數據包類型需要符合RFC規定,這就好像每個數據包都要有完整規范的著裝,只要不符合規范,就自動識別並將其過濾掉。(3) 特定應用防護:非法流量總是有一些特定特徵的,這就好比即便你混進了顧客群中,但你的行為還是會暴露出你的動機,比如老重復問店員同一個問題,老做同樣的動作,這樣你仍然還是會被發現的。(4) 帶寬控制:真實的訪問數據過大時,可以限制其最大輸出的流量,以減少下游網路系統的壓力。
2、CSRF(Cross Site Request Forgery),即跨站請求偽造,是一種常見的Web攻擊,但很多開發者對它很陌生。CSRF也是Web安全中最容易被忽略的一種攻擊。
防範:(1) 驗證碼。應用程序和用戶進行交互過程中,特別是賬戶交易這種核心步驟,強制用戶輸入驗證碼,才能完成最終請求。在通常情況下,驗證碼夠很好地遏制CSRF攻擊。但增加驗證碼降低了用戶的體驗,網站不能給所有的操作都加上驗證碼。所以只能將驗證碼作為一種輔助手段,在關鍵業務點設置驗證碼。(2) Referer Check。HTTP Referer是header的一部分,當瀏覽器向web伺服器發送請求時,一般會帶上Referer信息告訴伺服器是從哪個頁面鏈接過來的,伺服器籍此可以獲得一些信息用於處理。可以通過檢查請求的來源來防禦CSRF攻擊。正常請求的referer具有一定規律,如在提交表單的referer必定是在該頁面發起的請求。所以通過檢查http包頭referer的值是不是這個頁面,來判斷是不是CSRF攻擊。但在某些情況下如從https跳轉到http,瀏覽器處於安全考慮,不會發送referer,伺服器就無法進行check了。若與該網站同域的其他網站有XSS漏洞,那麼攻擊者可以在其他網站注入惡意腳本,受害者進入了此類同域的網址,也會遭受攻擊。出於以上原因,無法完全依賴Referer Check作為防禦CSRF的主要手段。但是可以通過Referer Check來監控CSRF攻擊的發生。(3) Anti CSRF Token。目前比較完善的解決方案是加入Anti-CSRF-Token,即發送請求時在HTTP 請求中以參數的形式加入一個隨機產生的token,並在伺服器建立一個攔截器來驗證這個token。伺服器讀取瀏覽器當前域cookie中這個token值,會進行校驗該請求當中的token和cookie當中的token值是否都存在且相等,才認為這是合法的請求。否則認為這次請求是違法的,拒絕該次服務。這種方法相比Referer檢查要安全很多,token可以在用戶登陸後產生並放於session或cookie中,然後在每次請求時伺服器把token從session或cookie中拿出,與本次請求中的token 進行比對。由於token的存在,攻擊者無法再構造出一個完整的URL實施CSRF攻擊。但在處理多個頁面共存問題時,當某個頁面消耗掉token後,其他頁面的表單保存的還是被消耗掉的那個token,其他頁面的表單提交時會出現token錯誤。
3、XSS(Cross Site Scripting),跨站腳本攻擊。為和層疊樣式表(Cascading Style Sheets,CSS)區分開,跨站腳本在安全領域叫做「XSS」。
防範:(1) 輸入過濾。永遠不要相信用戶的輸入,對用戶輸入的數據做一定的過濾。如輸入的數據是否符合預期的格式,比如日期格式,Email格式,電話號碼格式等等。這樣可以初步對XSS漏洞進行防禦。上面的措施只在web端做了限制,攻擊者通抓包工具如Fiddler還是可以繞過前端輸入的限制,修改請求注入攻擊腳本。因此,後台伺服器需要在接收到用戶輸入的數據後,對特殊危險字元進行過濾或者轉義處理,然後再存儲到資料庫中。(2) 輸出編碼。伺服器端輸出到瀏覽器的數據,可以使用系統的安全函數來進行編碼或轉義來防範XSS攻擊。在PHP中,有htmlentities()和htmlspecialchars()兩個函數可以滿足安全要求。相應的JavaScript的編碼方式可以使用JavascriptEncode。(3) 安全編碼。開發需盡量避免Web客戶端文檔重寫、重定向或其他敏感操作,同時要避免使用客戶端數據,這些操作需盡量在伺服器端使用動態頁面來實現。(4) HttpOnly Cookie。預防XSS攻擊竊取用戶cookie最有效的防禦手段。Web應用程序在設置cookie時,將其屬性設為HttpOnly,就可以避免該網頁的cookie被客戶端惡意JavaScript竊取,保護用戶cookie信息。(5)WAF(Web Application Firewall),Web應用防火牆,主要的功能是防範諸如網頁木馬、XSS以及CSRF等常見的Web漏洞攻擊。由第三方公司開發,在企業環境中深受歡迎。
4、SQL注入(SQL Injection),應用程序在向後台資料庫傳遞SQL(Structured Query Language,結構化查詢語言)時,攻擊者將SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串,最終達到欺騙伺服器執行惡意的SQL命令。
防範:(1) 防止系統敏感信息泄露。設置php.ini選項display_errors=off,防止php腳本出錯之後,在web頁面輸出敏感信息錯誤,讓攻擊者有機可乘。(2) 數據轉義。設置php.ini選項magic_quotes_gpc=on,它會將提交的變數中所有的』(單引號),」(雙引號),\(反斜杠),空白字元等都在前面自動加上\。或者採用mysql_real_escape()函數或addslashes()函數進行輸入參數的轉義。(3) 增加黑名單或者白名單驗證。白名單驗證一般指,檢查用戶輸入是否是符合預期的類型、長度、數值范圍或者其他格式標准。黑名單驗證是指,若在用戶輸入中,包含明顯的惡意內容則拒絕該條用戶請求。在使用白名單驗證時,一般會配合黑名單驗證。
5、上傳漏洞在DVBBS6.0時代被黑客們利用的最為猖獗,利用上傳漏洞可以直接得到WEBSHELL,危害等級超級高,現在的入侵中上傳漏洞也是常見的漏洞。該漏洞允許用戶上傳任意文件可能會讓攻擊者注入危險內容或惡意代碼,並在伺服器上運行。
防範: (1)檢查伺服器是否判斷了上傳文件類型及後綴。 (2) 定義上傳文件類型白名單,即只允許白名單裡面類型的文件上傳。 (3) 文件上傳目錄禁止執行腳本解析,避免攻擊者進行二次攻擊。 Info漏洞 Info漏洞就是CGI把輸入的參數原樣輸出到頁面,攻擊者通過修改輸入參數而達到欺騙用戶的目的。