為什麼網站登錄窗口要在另一個網址?

最近做一個博客網站,想借鑒一下其他大網站的經驗,想把登錄界面放在頂端.

結果發現很多網站都是有登錄和註冊兩個按鈕.

點進去又是一個新網站(二級域名不同),來進行登錄,我不明白這樣做的原因.

難道是用戶體驗需求?

補充================

之前有個回答說豆瓣就是這樣.把登錄界面放在首頁,我看了一下,覺得並不是這樣.

只不過它在登錄界面加了一些豆瓣的文字和圖片.本質上還是那樣.

如豆瓣有:電影,音樂,讀書等子網頁.點開之後,登錄時仍然是重新開一個二級域名.

所以我現在找不到一個符合大家說的採用ajax的網站.還是壓根兒沒有

由於是小白.只是單純做作業,做一個簡單的前台和後台,並沒有考慮太多.= =懂得太少,不會術語請見諒


瀉藥,,,

===============================

用戶體驗個屁!!!

用戶體驗個屁!!!

用戶體驗個屁!!!

不用動不動就用戶體驗,用戶體驗,用戶體驗,別整這麼高大上的用詞!

那些個跳轉登錄都是個屁的用戶體驗。

無調轉,無刷新登錄才是最好的登錄體驗!!!

為嘛? 無非架構設計、性能均衡、分散式、安全、費用、維護等等來考慮的。

一.打開新網頁登陸,是因為伺服器對登錄這一塊單獨做了https化。

並不是每個域名都需要走https的,https的服務費是很貴的。

走https協議比較消耗資源、帶寬、伺服器運算能力。

所以一般上了規模的網站,會把涉及到敏感信息的表單提交頁面都走https,但域名你可是要知道的,只有一個主域名喲,難道所有http://www.test.com域名都走https?

不的,所以會開一個http://port.test.com域名只用來做敏感信息提交處理。

所以外行眼中看來,是另一個網站了,其實呢,它們都是http://test.com域名下的子域名,並沒有差別。

二、大集團之間進行了個系統整合,但域名卻是不一樣的。

所以需要一個中間域名做登錄再跳轉。

這樣的例子比如萬網,需要跳轉至阿里雲進行登錄,登錄後跳回萬網。

至於為什麼? 因為萬網之前並不是阿里的,是被併購的。

三、又要集中處理敏感數據,又都走https的。

比如百度,阿里,騰訊,他們財大氣粗,所以可能都走了https。

但你要知道,他們之前都是走http的,歷史遺留問題,和架構之初留下的框框並不是說改就改的。

所以他們會有一、二兩種情況的結合。

至於你想知道為什麼?

請搜索 https 、域名、 子域名、DNS 、掌握了一定的網站開發架構再來看這個!

以上,,,

我發現我很啰嗦,文字整理功力有限啊,摔


樓上有幾位哥們提到是因為單點登錄或者https,我認為這不是頁面跳轉的原因或者索性說借口,因為單點登錄及https通過彈窗依然可以實現登錄和註冊,這並不衝突

至於發生了頁面跳轉,只要登錄/註冊後能回到瀏覽頁面,在用戶體驗上一般不會有太大影響

只有開放平台的登錄(使用oAuth協議)或者登錄完成後頁面上較多元素需要重新刷新的情況下才非用跳轉登錄/註冊

剩下的情況,可以理解為用戶體驗不好,至少是網站開發者沒有花足夠的成本去部署全站登錄統一的js控制項


真正的原因是工作量大。

功能集成度越高,用戶體驗就越好,但開發過程中要考慮與處理的狀態機就越多。

舉個例子,如果A頁面為首頁,B頁面為單獨的登錄頁面,那麼A頁面上的一個功能模塊,最少只需要考慮以下兩個狀態:

1.如果用戶未登錄,則顯示登錄按鈕。

2.如果用戶已經登錄,則顯示用戶信息。

當你為了提高用戶體驗,把登錄功能直接集成到A頁面上,那麼問題來了,對於這個功能模塊,你還必須考慮:

3.當用戶正在輸入登錄信息時,要做些什麼?比如要不要把用戶目前輸入的信息去做自動完成,並且展開對此搜索到的結果?

4.當用戶輸完登錄信息並點擊了登錄按鈕後,要做些什麼?比如顯示:正在連接伺服器?

5.如果用戶登錄後,伺服器反饋說登錄失敗,原因是用戶不存在,那麼要做些什麼?比如問問用戶是不是輸錯了,然後對用戶輸入的名字進行聯想或糾錯,並且給出結果?

6.如果用戶登錄後,伺服器反饋說登錄失敗,原因是密碼錯誤,那麼要做些什麼?比如告訴用戶找回密碼的幾種方式?

7.如果用戶登錄後,伺服器反饋說登錄失敗,原因是用戶已經在另一個地區登錄了,那麼要做些什麼?比如提示用戶修改密碼?

8.如果用戶登錄後,伺服器反饋說登錄失敗,原因是系統發生內部未知錯誤,那麼要做些什麼?比如把錯誤詳細信息的加密後字元串顯示出來,並且告知用戶去反饋?

9.如果用戶登錄後,伺服器反饋說登錄成功,下一步肯定是要開始載入用戶信息,但在這之前要做些什麼?比如顯示正在載入用戶信息?

10.開始載入用戶信息,要做些什麼?

11.載入用戶信息超時,要做些什麼?

12.載入用戶信息出錯,要做些什麼?

13.載入用戶信息成功,下一步肯定是要顯示用戶信息,但在這之前要做些什麼?

等等....

你會發現,你考慮地越細,用戶體驗就越好,狀態機就越多,工作量就越大。最後:

領導:小王,一個登錄頁面你已經做了半個月了都還沒做完,你究竟在幹嘛?

小王:領導好,我昨天已經實現了登錄失敗時的語音自動播報錯誤信息,以及給出建議,今天要做的是處理語音的立體度,以及適當增加大廳混響效果。

領導:......


應該就是上面很多人都說了的單點登錄,如果各個功能模塊(子站)都是獨立開發的,但是希望共享用戶數據,就會把用戶註冊認證也作一個獨立的產品來維護然後提供認證和信息介面給其他子站調用。當然,只是單點登錄技術上倒確實沒必要一定要跳轉域名,但如果由我規劃,我大概也會做成統一跳轉,我能想到的優點有幾個

1 減少重複工作量,提高安全性。每個子站點/產品都可以少做幾個頁面,尤其這些頁面還涉及安全,子產品線碰上不靠譜程序員的可能性很高,把註冊登錄頁面都統一做可以減少不可控因素。

2 維護上的好處,萬一頁面有bug,或者認證介面有修改,各個子產品都不用去考慮更新認證頁面的問題,只要通行證系統那邊統一修改了就好。

3 可以確保不同渠道註冊的用戶信息的一致性(若有的子產品壓根不需要用到一部分信息,如果由自己做註冊頁面,這部分「多餘」的信息有可能就直接傳個默認值過來完事)

4 可以確保用戶體驗的一致性,註冊登錄頁面完全一樣,地址也一樣,可以讓用戶很明確地認識到「這是同個地方,用同一個賬號」,不然如果旗下幾個子產品風格差異比較大,註冊頁面自己做風格也差的大,用戶很可能壓根意識不到其實用同個賬號就可以。


非專業人士,胡謅八扯一下。可能是為了美觀,在不改變原網頁內容的情況下,實現登陸?


說了多少次,是 登錄 不是 登陸。


簡單就是最好的用戶體驗。而且不管如何,單獨的登陸頁面是必須存在的——無論是不是做了彈出的菜單,因為,就是會有特定的場景需要這個頁面。


很多都沒說到點子上,和https有點關係但不是關鍵,其實這麼做就是為了模塊化和解耦。

為什麼登錄要單獨頁面,因為全站就可以用這麼一套前端了啊,多省事,要做在首頁一起改個邏輯還得改兩遍,還是兩個團隊的人維護,絕對會是大坑。這是大型應用才需要的東西,自己做不需要考慮。


有一種結構,叫sso


這純粹是歷史遺留的習慣, 在Ajax技術沒出現之前, 根本實現不了原地無刷新登錄.

至於單點登錄, https當然需要獨立的登錄系統. 但更多的網站, 我相信是受習慣惰性和老闆的審美做出來的.


把用戶系統獨立出來,這樣同一家公司的每個平台都可以共享同一個用戶系統


簡單地說以前都是直接刷頁面的,後來才有ajax。然而登入屬於關鍵但不重要的業務,誰沒事三天兩頭升級搞ajax內嵌還得維護調試兼容性。

工程的角度上看,簡單穩定歷史原因

單點sso啥的一點關係都沒,在登入的時候會調用sso介面寫cookie和記錄分散式session,下一個請求在服務端看來就已經是登入狀態了。

新頁面屬於直接跳轉到登入應用的功能頁面,而彈出窗口則是調用了登入ajax介面。唯一的區別僅僅是交互方式不同,客戶端實現不同。

我感覺登入更準確一些。


回答下,我們正在做這個

登陸部分用子域名的原因有以下幾點

排列按需求優先度

1 單點登錄 sso 目的是實現旗下網站登錄一次 全站訪問 防止跨域 ,sso 也是一種 oauth 需要在認證機交換token

2 統一登陸 解耦 之前的登陸代碼有四五套,由於登陸機制調整了三次,不同業務模塊卻用不一樣的登陸代碼 每個地方都要改

3 部分使用 https。整站使用https是沒必要的,登陸 支付這塊需要 一般查詢的地方沒必要。防劫持可以 cps


哪是什麼https的原因,https服務怎麼就貴了?

怎麼就跟用戶體驗無關呢?

這不就是單點登錄嘛,就是大公司所謂的通行證嘛,你想像一下,公司有幾十個產品線,難道每個產品線都要維護自己的用戶信息嗎,就拿百度來說,我註冊一個百度賬號,百度全家桶我都可以登錄的呀,這難道不是在提高用戶體驗嗎?

說回單獨的域名,不搞個單獨的域名你說我該跟哪個產品線一個域?

在大公司賬號體系是作為一個獨立的服務為公司其他產品線提供登錄註冊支持的……

至於你是新開一頁還是搞個彈窗那就看各個產品線產品經理了……


第一眼以為是說那些經常換網址的小網站呢

進來才發現都是說技術的

羞恥匿名跑


回答的都是什麼鬼,角度不同目的肯定不一樣啊

——————————

要是從技術方面講,模塊化與組件化是關鍵,前端組件做好以後調用異常便捷,模塊化的話主要針對業務邏輯與資料庫交互

——————————

要是從用戶體驗什麼出發

那就隨便了,無數個人有無數個愛好用法,你咋知道百分之99用戶喜歡這個

——————————

這問題本身就有問題,因為技術上實現任何一種都是沒問題的,但是歷史上肯定有人這麼干跌倒了,所以你會發現沒恐龍了


當你一個網站很小的時候 所有功能都寫在一個程序里 使用一台伺服器 ,當你網站越來越大 伺服器壓力已經扛不住了 為了性能優化就得將功能拆分了 比如把登陸 購物流程什麼的都拆出來 這樣不僅性能優化了 當某個服務掛了的時候也不至於整個網站就都廢了。還有這些都是二級域名不一樣而已 不是一個新網站


不認同用戶體驗的說法,也不認同 HTTPS 的說法。應該是為了業務分離,更加安全可控。


豆瓣就不是啊,除非你輸入錯誤

這麼做的原因可能是因為有些網站要做單點登錄


以前是沒有ajax這種東西的


推薦閱讀:

ARVR的界面適合延續現在手機的扁平化界面設計嗎?
中文字體會不會與簡潔的 iOS 7 的扁平設計格格不入?
什麼是『設計思維』(Design thinking)?
圓形屏幕上的界面和交互設計有什麼特點,有哪些典型?
用戶體驗行業現在面對的機會和挑戰有哪些,用戶體驗人需要做好怎樣的準備?

TAG:用戶體驗 | PHP | 用戶體驗設計 | HTMLCSS | 後台技術 |