Problems, need help? Have a tip or advice? Post it here.
29 posts Page 2 of 3
Sorry, cheesypoof, but you're terribly wrong, unless my eyes deceive me.
I've read the logic from the CODE.
Allow me to explain.
setcookie's function THIRD parameter was set to ZERO instead of $cookie_expiry, which in turn was set to 12 hours. Instead of being passed as a parameter to a function, it is only used in HASH, which is clearly not enough.
The line of the code you are referring to is this -
Code: Select all
setcookie($this->cookie_name, $cookie, 0, $this->cookie_path, null, null, true);

The THIRD parameter is indeed set to ZERO and that means that this cookie will remain in the client's browser for only as long as the browser remains open. 'Ephemeral' (or session) as I mentioned in my last post.

Which means that if the user keeps the browser open for, say, months together the cookie will always be returned by the browser to the server.

However, that cookie will *not* be accepted by Couch after 12 hours of the time it was first issued. This is ensured by the cookie content (implemented using the industry standard ' Secure Cookie Protocol - by Alex X. liu') that has the initial issue time within it.

When a cookie is presented, the login function (function _authenticate_cookie() in auth.php) compares the contained time with the current time and rejects the cookie if found stale
Code: Select all
$cookie = $FUNCS->cleanXSS( $_COOKIE[$this->cookie_name] );
list( $username, $expiry, $hash ) = explode( ':', $cookie );
if( time() < $expiry ){
   if( $cookie == $this->create_cookie($username, $expiry) ){// if cookies match

it is only used in HASH, which is clearly not enough.
The thing MIGHT work with very old PHP version though.

It is enough for what it is meant to be - that is to securely tell the server the original issue time of the cookie. Not sure why it wouldn't work on *any* version of PHP.
When a variable is set a value and is not used where intended, it IS a bug, not a feature.
I think, I already explained that the variable is being used as intended.
version 1.4.5
There is not documented way to use $rememberme variable.
You'll find it in the docs about extended-users ( which is what it was meant for, for now.
But the logic suggests that even with NO rememberme button checked, the cookie must last for 24 hours.
Then the logic suggests that IF rememberme is not checked, the cookie expiration parameter is yet again set to ZERO instead of 24 hours.
I think your initial confusion about the cookies life-time (i.e. being sent by the browser back to the server) and the validity-time (being accepted by server if not more that 24 hours old) must have been resolved by the discussion above so that should answer this point.

May I ask for a less aggressive tone in your posts ?

It's always quite decent on this forum even on the obvious misunderstandings about couch the replies has been always helpful and understanding it would be neat to return the courtesy.
I load frameworks and write bugs on top of them, after that I rearrange the code so that it looks like a cool product.
OK, I'll delete my aggressive wordings, but a bit later when I calm down.
Thank you for understanding. ;)
No worries, @eklipse2009 :)
You'll always find this community open to discussion.
eklipse2009 wrote: Just agree that this behavior of the system is unexpected. When you press "Save" the system is supposed to SAVE or AT LEAST notify the user that the action is impossible.

I agree. I'll go farther and join you in being strident on the issue. No matter the particular details or the semantics of whether it is a bug or not, this is a serious flaw, and it's not limited to this one particular case, either. It's a systemic problem.

@cheesypoof said that data loss is highly regrettable, but I don't think that's strong enough. I would say that it's unacceptable. A good application should go out of its way to prevent any data loss, even in the case of user error. Unfortunately, in this regard Couch is woefully inadequate.

@KK and I both pointed out that saving work and taking steps to avoid losing it are any computer user's responsibility. But in my own line of work I've learned that it's fruitless to blame my customers even for their most egregious mistakes. Instead, I cheerfully help to correct the situation and think about what I can do to prevent the problem occurring for others. This last part is the most important.

If Couch were my product, I would set aside all other work and prioritize protecting user data against accidental loss. It's good business. Nothing will turn someone away like inexplicably losing a day's work. And it's good manners. It's disrespectful of users' work to treat their data so cavalierly.

I've lost data in pretty much every way conceivable using Couch. I'm pretty sure I've even run into this expired session bu... flaw. ;) You can also hit the back button, close the browser tab, refresh the window, or click a link in the admin panel if you'd like to erase all your work with no hope of recovery. Saving a page while there is a network problem is an especially exciting way to blow up your data. It's like playing Russian Roulette. Should I pull the trigger?

In the discussion that @cheesypoof and I had over this issue, I initially requested an autosave feature. Instead @cheesypoof proposed a javascript warning. It's a good idea and would go a long way toward limiting the risk. But in light of this discussion, I don't think that goes quite far enough. In the situation of an expired session or a network error, the warning wouldn't fire. In the case of a loss of power or spilled coffee, it would be useless.

An autosave that would periodically back up the current state to the database or perhaps to local storage may be a fundamental, necessary feature for Couch to adopt. At the very least, it needs more robust warnings about imminent loss of data. To my mind this is an urgently needed patch.

eklipse2009 wrote: The worst thing about it is that the user did not do anything unexpected by her fault, she HAD all the text ready and DID press the "Save" button.

It's inappropriate to dismiss this with technical minutiae. It's a horrible user experience resulting from a fault in the software. I say this as one of Couch's all-time biggest fans.

@eklipse2009, you were wondering about other serious issues. I think you've found Couch's biggest problem.
Please excuse that last bit as a rhetorical flourish. I've never known Kamran or cheesypoof to be dismissive.
+1 to all of your points.
The JavaScript warning thing was the first issue I've made sure is present in my Couch installation before even making the templates.
Saving a draft to local storage sounds like a good idea and definitely possible to implement.
I see it like that:
1. Use JavaScript to move data from ALL editable fields to localStorage on timer (say, every 5 minutes).
2. Purge localStorage variables on pressing "Save" button.
3. The user might forget about having unsaved draft or forget what exact page he/she was editing, so the following logic should be applied (in pseudocode):
Code: Select all
ON page refresh in Admin panel:
IF localStorage HAS draft:
ASK user in a DIALOG (message="You have unsaved draft of %page%.", buttons=["Edit draft", "Delete draft"])
ON button click Edit draft:
GOTO %page%.
LOAD all field values from draft.
ON button click Delete draft:
DELETE draft from localStorage.

Maybe I'll do it myself, but in some primitive form, because I'm not yet familiar enough with CouchCMS's code. Kamran or Cheesypoof would do it way better of course.
And why not add the javascript warning to the github repository?

I totally agree with you that dismissing the issue of potential data loss is a very bad move. That's why I became so irritated (most of my harsh language is already edited by myself).
An even better solution would be a MySQL table couch_drafts
Table couch_drafts must replicate the table couch_data_text.
There should be a function "SaveDraft", called by Ajax to prevent page reload, with the same code as that for the "Save" button, except that it saves to couch_drafts instead of couch_data_text.
"Save" button function makes DELETE FROM couch_drafts WHERE page_id = :page_id
:page_id = ID of the current page.
This seems even easier than localStorage solution, because allows having multiple drafts.
Also it would allow to roll changes back if the draft contains less data or different data from what originally was on the page and the user did not intend to save that.
hello eklipse2009, I have just built a Couch site for my husband who had a similar experience in losing a load of data by "leaning on the keyboard" and thought it was his own fault. As the creator of Couch websites it is easy to lose sight of the prime purpose which is to allow the client to easily and reliably update their site content. It is sometimes hard for us to credit the actions of our clients/users - but these things happen. In fact I suspect this type of thing happens to my clients and I never hear about it. They tend to blame themselves if things don't work or think they have broken something and it is their own fault. I guess I'm the original prime target user of Couch - a designer who is relying on the CMS to do the heavy lifting for me - so frustratingly I don't have the technical know-how to suggest solutions, but am relying on other contributors - @kk, @cheesypoof etc. For what it's worth I support the request for belts and braces in the quest for helping our clients out in the unreliable environment in which they update their sites and am grateful to whoever can help achieve this. I know that however much I nag and persuade and cajole, clients will never follow a safe practice of keying in data in a text editor and copying it across to the Couch admin panel!
I agree that this is frustrating and we must attempt to prevent data loss wherever it may be possible. You've all gone to great detail to try and suggest fixes for this issue in the form of warning the user and/or new database tables to save the data etc. While these have all been good suggestions, I don't see why couch needs to implement any new tables or make HUGE adjustments for this.

My suggestion is that we use the already implemented drafts feature. If the cookie is expired upon save, the user should be notified. The data should then be saved so that the user can retrieve it when they wish. The easiest way to do this would be to save the data as a draft. This would solve the data loss (by saving the data in a non-publicized place for the user to retrieve later) They should of course be notified that it is now a draft (and possibly redirected to that when they log back in from their timed out session).

That's just my 2 cents on the subject, though. :)
29 posts Page 2 of 3