1. Javaweb中我想在登陸界面輸入用戶名和密碼，然後驗證，對了跳轉到登陸成功的頁面，不對就跳到首頁
在登錄頁面的提交按鈕上注冊提交事件，在注冊事件中使用JS獲取到輸入的用戶名和密碼，然後和你寫死的固定值進行比較，如果正確，直接跳轉到別的頁面，失敗就刷新當前頁面
2. web登陸界面為什麼不跳轉
您好，您描述的現象可能是手機或電腦設置了CMCC-EDU自動鏈接；同時，目前WLAN認證界面提供「每次打開瀏覽器自動登錄」的功能。兩者結合後，就出現您打開WiFi後，自動連接CMC-EDUC網路，再打開瀏覽器就自動登錄，不用再認證登錄，直接可以訪問網頁。如果您希望調整此現象，可以嘗試如下操作：1、刪除CMCC-EDU鏈接後重新建立。2、重啟終端後，再次打開瀏覽器，此時會顯示WLAN登錄界面，是已登錄狀態，您將「每次打開瀏覽器自動登錄」前面的√選沒，再次登錄即可。
3. 讓WEB鏈接完美的跳轉到APP客戶端怎麼做
讓WEB鏈接完美的跳轉到APP客戶端怎麼做的解答如下
在一般情況下，這種跳轉優化根據設計的無縫度會有四種，總結如下（在此聲明，我所測試的所有App都是我個人比較喜歡的，所以不存在詆毀哪款產品問題）：
第一種：鏈接是為PC設計的，根本沒有針對移動設備進行過優化，打開鏈接你必須通過縮放才能看到網頁上的內容。這類App有很多，比如大眾點評、果殼、果庫、抬杠等。
第二種：鏈接為移動設備優化過，但從網頁端轉到移動端仍然有斷層。比如美樂時光官方微信會推薦一些歌單，我用瀏覽器打開後便可以直接播放，移動體驗非常棒，但即便登錄之後也不能對播放的歌曲進行收藏。如果我想收藏某些歌曲，必須用電腦打開網站，搜到歌曲，然後收藏後才會同步到美樂時光App上，非常的麻煩。另外這類App還有：想去、美團等。
這裡面還有一種情況，就是媒體類應用。由於媒體本身產生的內容只是一篇篇文章，所以很容易為移動設備優化。但這又分兩類，一類本身網頁在移動設備上的體驗非常好，同時也有客戶端，但兩者是有斷層的。第二類是對移動端進行了優化，但由於沒有客戶端，反而不會出現上體驗斷層的問題。
第三種：產品本身就是為移動而生的，即便是網頁版，也像移動端一樣簡潔。這種鏈接打開沒任何壓力，即便登錄，也是非常方便的。你可以直接用網頁版進行各種操作，然後打開App就能同步了。這種情況已經算是非常好的了，但它仍然無法解決網頁鏈接和App之間的鴻溝問題，我不能直接通過網頁鏈接打開App。這類產品比較少，比如早期的果庫（無網頁版）、國外的Fancy等。
第四種：點擊鏈接可以直接打開App，如果是在桌面端則直接在瀏覽器中顯示內容。在我測試的十幾款App中，我只發現了兩款在網頁鏈接向App跳轉上做得非常好，那就是啪啪（Papa）和Instagram。我在刷微博看見好友分享了一條啪啪時，點擊鏈接，我的啪啪就會自動打開，然後顯示好友分享的內容。而Instagram做法有些不同，它第一次打開的是優化過的網頁，然後Logo旁有一個「Open in app」的按鈕，點擊之後可以直接打開App。這樣就非常方便，如果我沒有安裝app，那麼它會直接在手機瀏覽器里打開，如果我用的是電腦，那它也會直接在桌面瀏覽器中打開。
4. web中登錄界面驗證碼成功後跳轉另一個html
一般情況下，登錄界面的驗證碼成功後，需要在後端對驗證碼進行驗證。驗證成功後，可以通過後端控制器返回帶有跳轉url參數的json數據給前端。前端在接收到該數據後，從中讀取跳轉的目標html頁面的url參數，並且使用`window.location.href`方法跳轉到目標則枯銷頁面的url。這樣就可以通過驗證碼驗證敗擾，並且自動跳轉孫游到想要的頁面了。另外，可以使用session等技術維護登陸狀態，保證用戶在跳轉後不需要重新進行登陸。
5. 如何在web.config裡面設置頁面跳轉問題
<?xml version="1.0"?>
<configuration>
<appSettings/>
<connectionStrings/>
<system.web>
<compilation debug="true" targetFramework="4.0"/>
<pages ="3.5" clientIDMode="AutoID"/>
1, 在這里開始設置
<authentication mode="Forms">
<forms loginUrl="login.aspx" defaultUrl="index.aspx" name="aspx"></forms>
loginUrl是指登錄的頁面，defaultUrl是指登陸後默認的顯示頁面，name就隨便寫
</authentication>
<authorization>
2. <!---拒絕所有匿名用戶訪問項目下的所有文件-->
<deny users="?"/>
3. <!--設置所有用戶都可以訪問項目下的所有文件-->
<!--<allow users="*"/>-->
</authorization>
</system.web>
設置為登錄頁面
<location path="login">
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
4. 上面的設置完成之後，會出現一個問題就是圖片不出，然後在加上下面的代碼就可以了
</location>
<location path="images">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
5.因為這里涉及到驗證碼的問題，path就是指的驗證碼的頁面，這一步是跟著上一步來的，需要把
驗證碼的頁面放在images文件夾下面，然後在驗證碼頁面把指向驗證碼的路徑改為在images/ValidateCode. aspx;
<location path="ValidateCode.aspx">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
</configuration>
6.登陸頁面的後台：
protected void 登陸_Click(object sender, EventArgs e)
{
FormsAuthentication.RedirectFromLoginPage(txtusername.Text,false); //txtusername就是用戶登錄時用戶名；
}
7.index頁面後台（這里指登錄之後默認顯示的頁面）
if(!IsPostBack)
{
Response.Write(Context.User.Identity.Name);
}
注意：在整個項目中，無論點擊那個頁面都會跳轉到登錄頁面；登錄成功之後才會跳轉到自己剛剛指定的頁面。
6. javaweb如何實現用戶在一個頁面長時間不操作自動跳轉到登錄頁面
設置Session超時時間,超時時長內,如果用戶沒有任何操作,Session就會自動過期.你在代碼里先取Session,如果沒有取到,就跳轉到登錄頁面即可.
7. 淺談web登錄
web登錄是網站上經常會遇到的功能，雖然看似簡單。但要做好易用性和引導性，還需要在設計和交互上達到平衡。
這里將要探討登錄流程中的頁面跳轉模式、登錄類型、以及登錄流程中的各種細節優化。
一、登錄頁面的兩種跳轉模式：
1、獨立頁面登錄
這種登錄方式的優點是比較正式與美觀，可以將網站更多的信息展示給當前用戶，包括大圖所展示的品牌形象，並可以提供更多的鏈接選擇（如：導航鏈接、多語言切換等等），當用戶在登錄過程中臨時起意需要放棄當前操作時，可以方便跳轉，（雖然並不是常見操作，且不推薦，卻仍為用戶提供便利性）。
但這種方式也有一定的缺點，對於瀏覽實時性比較強的網站，頁面的跳轉會破壞其操作的連貫性。並且眾多強迫症患者還會有一種，登錄完成後是否還能回到現有頁面的疑慮。事實上這種情況也確實存在。
2、當前頁面彈出窗口登錄(模態窗口)
這種方式的好處在於避免頁面跳轉對操作連貫性的破壞，把登錄對用戶造成的影響降至最低。
PS:所謂的模態窗口，是指在用戶想要對對話框以外的應用程序進行操作時，必須首先對該對話框進行響應。如單擊「確定」「取消」按鈕等將該對話框關閉。
關於兩種登錄模式的選擇，主要看用戶在使用登錄模塊時的情境。例如，未登錄狀態，若直接點擊「登錄」按鈕或「個人中心」，沒有涉及到其他功能的使用，便跳轉至獨立頁面。而當需要進行某項操作，必須登錄後才可進行時，建議使用彈出窗口，以保持操作的連貫性。
淘寶、豆瓣均為此模式。點擊「登錄」按鈕時，跳轉至獨立頁面；而點擊「立即購買」或「收藏」「評論」等功能性按鈕時，顯示彈出層登錄窗口。
二、登錄的兩種類型：
關於登錄的類型，一般有兩種，一種是郵件/用戶名/手機號登錄，另一種是第三方登錄。
1、郵件/用戶名/手機號登錄
這是一種比較常用和傳統的登錄方式，輸入用戶名/郵箱/手機號和密碼便可直接登錄。值得一提的是，之前的大部分網站僅支持用戶名登錄，而不支持使用郵箱或手機號登錄。但這種方式存在的問題就是注冊時，有可能會因為用戶名已被其他用戶注冊的限制而進行強制更改，導致注冊的網站越多，越容易忘記用戶名。
但郵件地址和手機號由於受到真實資料及數量上的限制，基本不會出現這種情況。所以，現在越來越多的網站都開始支持多種帳號形式登錄的方式。
2、第三方登錄
這種登錄方式是指通過其他的社交帳號來進行授權登錄的一種方式，目前這種方式在很多網站上都有採用。其優點是簡單快速，降低用戶注冊門檻及用戶流失數量。尤其是對於中小型的非常用網站，或僅想嘗試當前功能的用戶來說，減小了其登錄成本。但這種方式也有一些致命的缺點。例如，當第三方的帳號被封號或被盜時，其他使用該帳號進行登錄的網站基本都不可用了。
這里要說到，目前有某些網站，支持第三方登錄，但是登錄成功後，還需要單獨填寫非重復的用戶名以及密碼。這種重復填寫資料的行為更容易讓用戶產生抵觸心理。
以上兩種方式各有利弊，目前而言，對於需要搜集用戶詳細資料的網站，例如電商網站，更適合於單獨用戶注冊模式。如果使用第三方登錄，進而還需要再填寫其他資料的行為反而更加麻煩。而對於一般性的網站，簡單的用戶資料授權就已經足夠了，使用第三方登錄更為方便，也利於帳號的記憶與管理。
三、登錄過程中的優化：
1、未登錄時進行的操作，在登錄後，此操作自動生效。
例如，淘寶在未登錄時進行「收藏」或「購買」，登錄後會自動收藏或加入購物車，無需再重復登錄前操作。這是一種比較人性化的交互行為，因為在登錄前有此操作，並且為此功能進行了登錄，說明這已經是一個明確的用戶行為，基本不存在誤操作的可能性。所以在進行登錄後，自動完成此操作會更為便捷。當然，在自動完成登錄前操作時，有一個直觀可視化的交互動效，便能讓用戶更加清晰的理解當前操作已自動完成。瀏覽幾個其他網站，如、豆瓣、behance、均無此功能。
2、適時提供登錄需求
當用戶瀏覽頁面時，遇到必須登錄才能夠繼續進行的操作時， 無疑是一個掃興的行為。提高體驗的途徑，就是將登錄或注冊行為放置至最後一步才進行。
例如，在知乎的頂部以未登錄身份點擊「話題」欄目，則會彈出登錄提示框。雖然這個是用於已登錄用戶查看自己感興趣的「話題」，但卻會對未登錄用戶產生一定的阻礙。對於未登錄用戶來說，點擊「話題」按鈕後，直接跳轉至「話題廣場」不是一種更好的選擇么？當用戶找到自己感興趣的話題，需要關注此話題時，再彈出「登錄」或者「注冊」的提示。這樣，也給用戶一個更為充分的理由。
另外，縱觀目前大部分電商網站，基本上都支持未登錄就可將商品放入購物車的操作行為。這個相比以前的體驗，也基本做到了盡量在最後一步才讓用戶選擇登錄的原則。但仔細想想，這其實是可以再進一步去完善的。目前的電商網站數量繁多，在某個網站只有一次購物經歷的機會將大大增加。當用戶沒有做好去注冊成為會員的准備時，為何不在加入購物車後，支持用戶登錄/注冊的同時，也支持未登錄直接付款並填寫購買人手機與收貨地址信息的功能呢。這個對於臨時購買的用戶來說，無異於會是比較順暢的操作體驗。也許當第一次購買流程順利完成後，用戶的注冊行為會更有誠意，而不是被迫進行。
登錄注冊雖然是一個很常見的功能，但卻是影響著整個網站體驗的重要一環。當新用戶的登錄注冊體驗受阻時，再精彩的內容也難以讓用戶回頭了。