Project

General

Profile

Actions

Bug #19530

closed

Store OpenID information in database instead of using the filesystem

Added by Oliver Hader about 16 years ago. Updated almost 15 years ago.

Status:
Closed
Priority:
Must have
Category:
-
Target version:
-
Start date:
2008-10-30
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.3
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

The OpenID information currently gets stored in the filesystem. Due to security reasons it's preferred to have that sensible data in the database.

The file to be changed is class.tx_openid_sv1.php

(issue imported from #M9683)


Files

9683.diff (13.6 KB) 9683.diff Administrator Admin, 2009-11-24 17:02
9683_v2.diff (15.5 KB) 9683_v2.diff Administrator Admin, 2009-11-26 10:28

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Feature #19409: Add support for OpenID authentication to TYPO3ClosedMartin Kutschker2008-10-03

Actions
Actions #1

Updated by Steffen Kamper about 16 years ago

Now in function getOpenIDConsumer FileStore of openID-lib is used. There is also a method SQLStore.php, so it should be no problem to switch.

Actions #2

Updated by Ingo Renner about 16 years ago

just make sure it's using the TYPO3 DB API

Actions #3

Updated by Dmitry Dulepov almost 15 years ago

Work is in progress.

Actions #4

Updated by Dmitry Dulepov almost 15 years ago

The patch is attached. This version is tested with trunk revision #6513 and the following OpenID providers and servers:
- Yahoo
- Google
- SimpleID

Since some users already use OpenID or backported it to 4.2, they may have troubles logging in to the system because of the store change (missing database tables). Therefore this patch includes elementary workaround that creates database on the fly if they are not there. This can be removed in TYPO3 4.4 but I suggest to release 4.3 with this code.

Actions #5

Updated by Marcus Krause almost 15 years ago

I was trying out the patch without luck. DB tables are in place.

I must admit OpenID never worked for me here.

I'm using Verisign as OpenID provider. I'll try to debug it.

Actions #6

Updated by Steffen Müller almost 15 years ago

Dmitry, thank you for the patch.

I also had no luck, it did not work with BE login. But OpenID worked for me before applying the patch.
I got the same effect as described in #21647 : OpenID provider redirects me to http://lenny.test/typo3/sysext/openid/ instead of the backend.

Also, I don't like the constructor checking and creating missing database tables. It's separate one-time code which blows up the class too much. install tool should do this. This is TYPO3 best practice and users are used to go through the database compare stuff for any other DB changes. It does not hurt. We had that before in trunk. IMHO this is a major issue I see with your patch.

I found also one minor issue:
DB compare in the install tool always shows:

ALTER TABLE tx_openid_nonce_store CHANGE salt salt char(40);
Current value: char(40) default ''

Pressing the "write to database" button does not change anything.

P.S. Tested by using launchpad.net as OpenID provider.

Actions #7

Updated by Dmitry Dulepov almost 15 years ago

Marcus, what would you say if somebody reported a problem to you like this: "I was trying out the patch without luck"? This is impossible to fix because it contains zero of information about the problem you have.

Steffen, I cannot confirm those redirections. I afraid you have to search your workspace for issues. Regarding table creation: this was for those who already use OpenID. The idea was to be user friendly and let them upgrade the system automatically. I will get rid of user friendliness in the new version of the patch. This would be true TYPO3 way: make it harder for users ;)

Actions #8

Updated by Steffen Müller almost 15 years ago

DB upgrate:
Dmitry, you know TYPO3 core is already very ugly code design. Upgrading database routines should be kept at a central place, since it is a repeating routine. With your solution we would later have duplicate code in the core, e.g. in each sysext.
On the other hand using the install tool for DB upgrade is well known and gives you full control about what happens to database tables.
You are right, this makes it harder for users to upgrade, but in a way, they are used with the above mentioned advantages.

Redirections:
I have already checked devlog/syslog for errors, but unfortunately there are none. Please give me some more time to debug it.

Actions #9

Updated by Dmitry Dulepov almost 15 years ago

rev 6580

Actions

Also available in: Atom PDF