I'm not redefining any subs after all, don't prevent those warnings.

[git.ikiwiki.info.git] / doc / bugs / login_page_should_note_cookie_requirement.mdwn

diff --git a/doc/bugs/login_page_should_note_cookie_requirement.mdwn b/doc/bugs/login_page_should_note_cookie_requirement.mdwn
index bd52f1c21f29cc4f4f04e25acd6aa8b23e674679..96686053ce2bacd44dab08ea7653f2f8da07421a 100644 (file)
--- a/doc/bugs/login_page_should_note_cookie_requirement.mdwn
+++ b/doc/bugs/login_page_should_note_cookie_requirement.mdwn
@@ -7,6 +7,10 @@ At the moment, you go through the login shuffle and then are told that cookies a
 >> Very few websites break without cookies.  Even fewer lose data.
 >> Can ikiwiki avoid being below average by default? --[MJR](http://mjr.towers.org.uk)
 
 >> Very few websites break without cookies.  Even fewer lose data.
 >> Can ikiwiki avoid being below average by default? --[MJR](http://mjr.towers.org.uk)
 

+>>> Can we avoid engaging in hyperbole? (Hint: Your browser probably has a
+>>> back button. Hint 2: A username/password does not count as "lost data".
+>>>  Hint 3: Now we're arguing, which is pointless.) --[[Joey]]
+

 Even better would be to only display the cookie note as a warning if the login page doesn't receive a session cookie.
 
 > I considered doing this before, but it would require running the cgi once
 Even better would be to only display the cookie note as a warning if the login page doesn't receive a session cookie.
 
 > I considered doing this before, but it would require running the cgi once


@@ -14,9 +18,16 @@ Even better would be to only display the cookie note as a warning if the login p
 > time to check if it took, which is both complicated and probably would
 > look bad.
 
 > time to check if it took, which is both complicated and probably would
 > look bad.
 

+>> Might this be possible client-side with javascript? A quick google suggests it is possible:
+>> <http://www.javascriptkit.com/javatutors/cookiedetect.shtml>. MJR, want to try adding
+>> that?  -- [[Will]]
+

 Best of all would be to use URL-based or hidden-field-based session tokens if cookies are not permitted.
 
 > This is not very doable since most of the pages the user browses are
 > static pages in a static location.
 
 Best of all would be to use URL-based or hidden-field-based session tokens if cookies are not permitted.
 
 > This is not very doable since most of the pages the user browses are
 > static pages in a static location.
 

->> The pages that lose data without cookies (the edit pages, primarily) don't look static. Are they really? --[MJR](http://mjr.towers.org.uk)
+>> The pages that lose data without cookies (the edit pages, primarily)
+>> don't look static. Are they really? --[MJR](http://mjr.towers.org.uk)
+
+>>> As soon as you post an edit page, you are back to a static website.