No content after fresh install (v1.3.0) #366

cryptosteve2 · 2013-12-25T20:04:59Z

Hi, I set up a new poche installation based on poche-1.3.0.zip. After performing the (correct) setup thats sqlite-based, I have no content in saved entries.

e.g. https://adler.crashmail.de/~stell/screenshots/screenshot-20131224@215357.png

Setup seems to be ok: https://adler.crashmail.de/~stell/screenshots/screenshot-20131225@072036.png

In a sqlite-installation I found this error message in the debug mode:
2013/12/25_10:52:37 - 178.3.140.119 - storage type sqlite
2013/12/25_10:52:37 - 178.3.140.119 - execute query error : SQLSTATE[HY000]: General error: 1 table tags_entries already exists

After that I switched to mysql and got this error (and cannot save any new links anymore):
2013/12/25_10:54:42 - 178.3.140.119 - execute query error : SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'title' cannot be null

After that, I start another fresh installation based von poche-1.0.0 and right after finishing this installation I upgraded to poche-1.3.0 ... an now it works. So, a fresh 1.3.0 doesn't work, a newly set up 1.0.0 upgraded to 1.3.0 works like a charm.

No idea where to search for a solution :)

nicosomb · 2014-01-03T08:39:01Z

Hello @cryptosteve2 !

Can you confirm I can close this issue?

cryptosteve2 · 2014-01-03T09:57:00Z

Sorry that I can not reproduce this bug (as a had that day for many times) ... yes, I think you can close this bug. I'll contact you (wiht my sqlite-db) if this issue occurs again.

fkieber · 2014-01-05T03:56:06Z

Same issue using sqlite and lighttpd.
Poche 1.2.0 works fine.
Upgrade to 1.3.0 always same db and web server does not resolve problem for new entries. Old entries are still visible.

nicosomb · 2014-01-05T09:00:29Z

Do you have errors in your lighttpd logs?

nicosomb · 2014-01-05T09:01:01Z

Can you run poche_compatibility_test.php (this file is in your poche folder)?

cryptosteve2 · 2014-01-05T09:57:38Z

nicosomb, as you asked in IRC I also use lighttpd. I had no errors in my log files.

nicosomb · 2014-01-05T10:17:28Z

Maybe the problem is here.
I don't know lighttpd, I'll install it and try to reproduce the bug.

fkieber · 2014-01-05T12:29:24Z

No errors in lighttpd log neither in php log.

With Poche 1.3.0 In acces.log I found

Loading poche home page

82.237.162.76 poche.frkb.fr - [05/Jan/2014:12:40:11 +0100] "GET / HTTP/1.1" 200 6465 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
82.237.162.76 poche.frkb.fr - [05/Jan/2014:12:40:13 +0100] "GET / HTTP/1.1" 200 6465 "http://poche.frkb.fr/" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"

Poching a page

82.237.162.76 poche.frkb.fr - [05/Jan/2014:12:40:20 +0100] "GET /?action=add&url=aHR0cDovL3d3dy5jbmlsLmZyL2RvY3VtZW50YXRpb24vZGVsaWJlcmF0aW9ucy9kZWxpYmVyYXRpb24vZGVsaWIvMTA3Lw== HTTP/1.1" 302 0 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
82.237.162.76 poche.frkb.fr - [05/Jan/2014:12:40:20 +0100] "GET /?view=home&closewin=true HTTP/1.1" 200 7576 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"

Refreshing home page

82.237.162.76 poche.frkb.fr - [05/Jan/2014:12:40:22 +0100] "GET / HTTP/1.1" 200 7456 "http://poche.frkb.fr/" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"

Compatibility test

82.237.162.76 poche.frkb.fr - [05/Jan/2014:12:43:10 +0100] "GET /poche_compatibility_test.php HTTP/1.1" 200 4719 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"

Test result

PHP 5.2.0 or higher 5.3.27-pl0-gentoo
XML Enabled Enabled, and sane
PCRE Enabled Enabled
Data filtering Enabled Enabled
Tidy Enabled Enabled
cURL Enabled Enabled
Parallel URL fetching Enabled Enabled
allow_url_fopen Enabled Enabled
What does this mean?

You have everything you need to run poche 1.0 properly! Congratulations!

Poche 1.0 ????? (maybe ok)

With poche 1.2.0

Refresh home page

82.237.162.76 poche.frkb.fr - [05/Jan/2014:13:10:47 +0100] "GET / HTTP/1.1" 200 11630 "http://poche.frkb.fr/" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"

Poching a page

82.237.162.76 poche.frkb.fr - [05/Jan/2014:13:12:07 +0100] "GET /?action=add&url=aHR0cHM6Ly9leHRlbnNpb25zLmdub21lLm9yZy9leHRlbnNpb24vNjAwL2xhdW5jaC1uZXctaW5zdGFuY2Uv HTTP/1.1" 302 0 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
82.237.162.76 poche.frkb.fr - [05/Jan/2014:13:12:08 +0100] "GET /?view=home&closewin=true HTTP/1.1" 200 13160 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"

Reloading home page

82.237.162.76 poche.frkb.fr - [05/Jan/2014:13:12:58 +0100] "GET / HTTP/1.1" 200 13040 "http://poche.frkb.fr/" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"

I see no differences !

nicosomb · 2014-01-07T19:45:27Z

Can you make a test with poche 1.3.1 please?

fkieber · 2014-01-07T23:28:28Z

Sorry ! Same result.
Old pages are still there.
New pages are empty.

fkieber · 2014-01-08T21:17:59Z

I have test a fresh install of 1.3.1.
Same result.
If I poche with firefox plugging or the Bookmarklet or when copying the link in the configuration page, the result is the same.

nicosomb · 2014-02-03T11:04:25Z

@cryptosteve2 @fkieber Can you test dev branch please? https://github.com/wallabag/wallabag/tree/dev

fkieber · 2014-02-04T12:05:55Z

Fresh install, same issue.
Title of every entry is : "Untitled"

Compatibility test gives :

wallabag 1: Compatibility Test
Test Should Be What You Have
PHP 5.2.0 or higher 5.3.27-pl0-gentoo
XML Enabled Enabled, and sane
PCRE Enabled Enabled
Data filtering Enabled Enabled
Tidy Enabled Enabled
cURL Enabled Enabled
Parallel URL fetching Enabled Enabled
allow_url_fopen Enabled Enabled
What does this mean?

You have everything you need to run wallabag 1 properly! Congratulations!

Bottom Line: Yes, you can!

Your webhost has its act together!

nicosomb · 2014-02-04T12:10:25Z

@Faless @mariroz @cryptosteve2 Can you reproduce this problem?

Faless · 2014-02-04T13:46:57Z

Hi @nicosomb .
I was able to reproduce this bug (not sure if with the same configuration of the original reporter).

The problem is that wallabag uses a third party library to convert the web page to something more readable. This library is called with file_get_contents on a local URL making an http(s) request to the local server.

I was experiencing this problem with previous versions since I was using Basic Authentication on apache. So I request to store the page, the server makes an http request to itself (third party library folder) without authentication failing due to 403 not authorized.

In your recent commit the issue was fixed for me since you added some lines in file inc/poche/Poche.class.php ( function getPageContent ) to provide the request with the same Basic Auth parameter received by wallabag to the third party library.

The problem is that you didn't consider the Digest Auth ( http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html ) so if the user is using a Digest Authentication method the problem is still there. Specifically if you add this to your apache config:

        <Directory /var/www/wallabag_dir>
                AuthType Digest
                AuthName "realm"
                AuthUserFile /var/htdigest
                Require valid-user
        </Directory>

and create the htdigest file with:

htdigest /var/htdigest realm user_name

You will be able to reproduce the problem.

I see two main ways to solve this problem:
1 - Implement Digest Auth as done for Basic Auth (but the problem will persist with other auth types)
2 - Modify the way you access to the third party library to not make an http(s) request to it but using it as a proper php library (may require some code changes in the library I think). Alternatively, you can try including the library using ob_start and ob_flush and "faking" some $_SERVER vars.

I'm sorry I cannot help you further in code developing for now since these days I'm really busy.

I hope you got the point since my English is far from perfect. If you have any doubt let me know.

mariroz · 2014-02-04T14:03:10Z

tnx to @Faless, reproduced this error by me too.
will try to fix.

mariroz · 2014-02-04T17:23:20Z

have worked a bit on the problem. Short conclusion is below.
according to ways, mentioned by @Faless :

this can not be done w/o extra workarounds as to add digest auth header we need plain password (to calculate complex md5).
it is what needs to be done and this is a proper way. But it require a lot of work and testing: it means, that we need to create own class/library taking makefulltextfeed.php in mind.
If you think it is really needed, I can try to do it, but, of course, will need more time.

However, as a temporary alternative solution, I can propose third way to work this problem out: once someone needs to use Digest auth, he can allow access to makefulltextfeed.php from any location (or from his host IP only). For example for Apache web server:

<Location /inc/3rdparty/makefulltextfeed.php>        
      Satisfy any
</Location>

this can help for some time.

mariroz · 2014-02-05T10:39:12Z

a bit more about how I see fix of the problem using way 1.
Our aim is to send properly constucted authorisation request to the server while we need to access /inc/3rdparty/makefulltextfeed.php from our script.
To bulid proper header, we need to have md5 sum of the next string:
"login:ralm:password".
So, possible way is to store this md5 instead of currently stored password hash.
This mean the next:

whlie creation a new user it will be required to enter his Digest auth password.
creation of the user has to be done obviously by creator, itself digest authenticated in the same realm (because we need to store realm name too).
I think, disadvantages of such approach are clear: authorisation will break once external digest password will change, will aslo break once digest auth will be removed, will not work for already created users w/o password update (site will work, but gettig of articles - not) etc. etc.
So, on my opinion, way 2 (re-development of makefulltextfeed.php - Full-Text RSS - to be called inline) is preferable, but, of course, much more laborious.
@nicosomb (or who is responsible for application design), pls let me know what solution should I try to implement, pls. It may depend on your plans for future (did you plan to use Full-Text RSS in v.2 of wallabag?) or even on amount of customers who use/will use Digest auth.

Faless · 2014-02-05T16:09:38Z

I implemented a patch that includes the script instead of using file_get_contents . It use a function scope to hide/restore the global context and the session so the 3rdparty library cannot access wallabag session and server vars.
I tested it in my installation and everything seems fine.
@mariroz @nicosomb please have a look here: ~~Faless@2547080~~ EDIT, see here: Faless@48cf3eb

mariroz · 2014-02-05T16:56:16Z

@Faless, have tested your solution: it works by me too.
interesting, that this did not come to my mind :).

Faless · 2014-02-05T16:58:01Z

@mariroz
Thanks, I changed the code a little bit (otherwise the library script would be able to access $REAL and $REAL_SESSION vars). The change is basically moving storing and restoring context outside $scope (of course!).
Have a look here: Faless@48cf3eb
And sorry for having you double check the commit

mariroz · 2014-02-05T17:08:48Z

@Faless , n.p. - tested new commit - works by me too.

fkieber · 2014-02-05T18:56:41Z

It work also with lighttpd.

@Faless

… Tnx to @Faless. Fix issues wallabag#366 and wallabag#463

nicosomb · 2014-03-01T09:57:09Z

Do you still have this problem with last version? (please test dev branch please)

cryptosteve2 · 2014-03-01T13:10:33Z

No, sorry, I can't reproduce this bug as I said before in
#366 (comment)

I had this issue the first days with poche/wallabag and never again
after this period. Strange, isn't it?

nicosomb · 2014-03-01T17:52:00Z

@fkieber is that good for you?

Can I close this issue?

fkieber · 2014-03-01T20:16:38Z

Great new theme.
It works for fresh install.
I test update later.

fkieber · 2014-03-01T21:45:10Z

I have test update.
Bagging works great.
Tank's.

nicosomb · 2014-03-01T21:46:06Z

Thank you!

nicosomb closed this as completed Jan 3, 2014

nicosomb reopened this Jan 5, 2014

aaa2000 mentioned this issue Jan 5, 2014

Create sqlite table tags_entries only if not already exists #382

Merged

nicosomb mentioned this issue Feb 3, 2014

Endless redirects or user doesn't exist with basic authentication #368

Closed

nicosomb closed this as completed Feb 3, 2014

nicosomb reopened this Feb 4, 2014

nicosomb added this to the 1.6.0 milestone Feb 12, 2014

nicosomb removed this from the 1.5.0 milestone Feb 12, 2014

mariroz mentioned this issue Feb 18, 2014

pages are not imported #463

Closed

mariroz added a commit to mariroz/wallabag that referenced this issue Feb 19, 2014

Full-Text RSS included as a script instead of file_get_contents call.…

b4fd215

… Tnx to @Faless. Fix issues wallabag#366 and wallabag#463

nicosomb closed this as completed Mar 1, 2014

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

No content after fresh install (v1.3.0) #366

No content after fresh install (v1.3.0) #366

cryptosteve2 commented Dec 25, 2013

nicosomb commented Jan 3, 2014

cryptosteve2 commented Jan 3, 2014

fkieber commented Jan 5, 2014

nicosomb commented Jan 5, 2014

nicosomb commented Jan 5, 2014

cryptosteve2 commented Jan 5, 2014

nicosomb commented Jan 5, 2014

fkieber commented Jan 5, 2014

nicosomb commented Jan 7, 2014

fkieber commented Jan 7, 2014

fkieber commented Jan 8, 2014

nicosomb commented Feb 3, 2014

fkieber commented Feb 4, 2014

nicosomb commented Feb 4, 2014

Faless commented Feb 4, 2014

mariroz commented Feb 4, 2014

mariroz commented Feb 4, 2014

mariroz commented Feb 5, 2014

Faless commented Feb 5, 2014

mariroz commented Feb 5, 2014

Faless commented Feb 5, 2014

mariroz commented Feb 5, 2014

fkieber commented Feb 5, 2014

nicosomb commented Mar 1, 2014

cryptosteve2 commented Mar 1, 2014

nicosomb commented Mar 1, 2014

fkieber commented Mar 1, 2014

fkieber commented Mar 1, 2014

nicosomb commented Mar 1, 2014

No content after fresh install (v1.3.0) #366

No content after fresh install (v1.3.0) #366

Comments

cryptosteve2 commented Dec 25, 2013

nicosomb commented Jan 3, 2014

cryptosteve2 commented Jan 3, 2014

fkieber commented Jan 5, 2014

nicosomb commented Jan 5, 2014

nicosomb commented Jan 5, 2014

cryptosteve2 commented Jan 5, 2014

nicosomb commented Jan 5, 2014

fkieber commented Jan 5, 2014

With Poche 1.3.0 In acces.log I found

Loading poche home page

Poching a page

Refreshing home page

Compatibility test

Test result

With poche 1.2.0

Refresh home page

Poching a page

Reloading home page

nicosomb commented Jan 7, 2014

fkieber commented Jan 7, 2014

fkieber commented Jan 8, 2014

nicosomb commented Feb 3, 2014

fkieber commented Feb 4, 2014

nicosomb commented Feb 4, 2014

Faless commented Feb 4, 2014

mariroz commented Feb 4, 2014

mariroz commented Feb 4, 2014

mariroz commented Feb 5, 2014

Faless commented Feb 5, 2014

mariroz commented Feb 5, 2014

Faless commented Feb 5, 2014

mariroz commented Feb 5, 2014

fkieber commented Feb 5, 2014

nicosomb commented Mar 1, 2014

cryptosteve2 commented Mar 1, 2014

nicosomb commented Mar 1, 2014

fkieber commented Mar 1, 2014

fkieber commented Mar 1, 2014

nicosomb commented Mar 1, 2014