You are not logged in. Please login or register.
PunBB Forums → Posts by webmeister
Pages 1
when i'm clicking on file to download it says 404 not found.
I should have tested that too. Now it finally works.
is this going to work with facebook connect? or google etc?
This extension only supports OpenID, and from what I can tell Facebook's/Google's solutions are not based on that technology (anymore).
links from first post says 404 not found
I've fixed the link. The site was still up, but apparently Redmine changed its URLs with some upgrade.
The extension has been developed for 1.3, so I'm not sure whether it is compatible with more recent versions.
Posting works, but you disabled the stop bot extension, didn't you?
I can't imagine that the OpenID extension causes any problems after you successfully logged in. From the viewpoint of the PunBB forum it does not matter which way you choose to log in. The OpenID extension just tells the forum "ignore the password error, the user is authenticated" and then the very same cookie is set that is used when you log in using your password. This cookie then identifies you on every subsequent request and tells the forum that you are still logged in. There is no difference using OpenID or not.
But I encountered another problem: When returning to the forum, I was logged out because of a timeout I think. The login page asked for a CAPTCHA (strangely the registration page didn't), but I couldn't solve it (it reported no CAPTCHA error but wouldn't go away either). The solution was to delete my cookies, then the login CAPTCHA was gone and the registration CAPTCHA appeared. Strange effects...
Somehow, I don't like this antispam extension. Is spam really such a problem, that one has to take such measures?
I'm trying to reproduce the error at your forum. The first registration (account "test") worked flawlessly. Now I try to register with a different OpenID but the same e-mail address. However, PunBB's wonderful flood protection delays my efforts... "A new user was registered with the same IP address as you within the last hour. To prevent registration flooding, at least an hour has to pass between registrations from the same IP."
The latest version is always announced in the first post. You can download it from here.
Think of OpenID as another way to prove who you are, so you can use it instead of your password. It can't entirely replace your PunBB account, so one is created on the fly when you try to log in using your OpenID. In the ideal scenario, you won't notice this step, but ideal in this case means:
your OpenID provider transmits your username and e-mail address using Simple Registration/Attribute Exchange Extension
neither your username nor your e-mail address are already taken (or otherwise considered invalid by PunBB)
PunBB does not use any extensions that require further user input (e.g. the antispam extension displaying the CAPTCHA)
As far as I know the repository only contains extensions written and supported by the official PunBB developers, so the decision to include my code is up to them. Parpalak seemed to be interested in the extension, but I do not know whether his tests succeeded.
This problem has already been discussed here. It should be possible to use the OpenID extension together with the Antispam extension, but when using OpenID to log in you still have to solve the CAPTCHA. I agree that the error message is a bit misleading, but this should be fixed in the Antispam extension (e.g. display a different error message, if the user did not enter a CAPTCHA text at all).
I use if (session_id() == '') session_start(); to avoid the notice in case a session has already been started.
There might be numerous reasons why the login fails. Do you get any error message? The only problem I ran into when using some providers was the use of SSL-secured connections. See the last paragraph in the post above.
You can use the library's consumer example to see if the library itself works with your OpenID. Additionally, there are some tests you can use to determine specific problems.
This error is triggered by JanRain's OpenID library. It tries to use /dev/urandom as a source of randomness, but this path isn't available on Windows. To fix this, add define('Auth_OpenID_RAND_SOURCE', NULL); to some global file (e.g. include/common.php) or change the statement at line 23 of Auth/OpenID/CryptUtil.php. The library will then use mt_rand() as its PRNG.
To bad it doesn't support the "big" OpenID providers like Yahoo and Google which are used by many of the main site users. Is there anything which can be done to enable them?
I know of no reason why these providers should not work. The providers mentioned in the first post are only those that I used for testing, so I'm sure that they work. But since all providers speak the same language (i.e. the OpenID protocol), others should work too. The OpenID library used by the extension supports both, OpenID 1.0/1.1 and 2.0, so there shouldn't be any problem with providers supporting only one of them.
Have you tried to log in using one of the providers you mentioned? Did you get any error message?
I just released version 1.1.0 of the extension. Some parts were rewritten for this release in order to simplify the code and to fix some other (mainly not user-visible) issues:
The format of the stored identifiers has changed. 1.0.x stored the user-supplied identifier in the database, while 1.1.x now uses the claimed identifier which is used for authentication at the OP and is thus closer to the OpenID specification. The old user-supplied identifier and the claimed identifier may actually be the same, but they can differ, if for example the user-supplied identifier redirects to some other URL. According to the OpenID specification the claimed identifier is the URL reached after following all redirects, while the user-supplied identifier was the URL before following any redirects. The installation procedure takes care of these changes and converts the identifiers when upgrading. If an identifier can not be converted automatically, you'll see a notice, and have to change it manually, but this may only happen, if the user-supplied identifier is invalid (e.g. because the OP is unreachable) and the user could not use it for login anyway.
This release now also supports login using XRIs, which was broken in all previous releases and has been fixed by the identifier format change. XRIs are only stored and displayed in the persistent i-number format, not as i-names. I-names can be used for login though. I didn't come up with a clean solution to display i-names while internally using i-numbers, but I assume that XRIs are scarcely used anyway and therefore not worth the effort needed for a nicer implementation. Please let me know, if I'm wrong here.
I considered adding OpenID icons at some spots, but here again I didn't find the ideal solution. Maybe this will be in one of the next releases.
While testing the new version, I discovered why some providers (e.g. ClaimID) cannot be used and fail with "server denied check_authentication". They use SSL to secure the connection between the forum and the provider (which is a good thing!), but my server fails to validate their certificate because he does not trust their certificate authority (CA). The simple (but insecure) fix is to deactivate certificate validation, which can be done by setting the appropriate cURL options in Auth/Yadis/ParanoidHTTPFetcher.php (I did not try the PlainHTTPFetcher.php, which is used, if cURL is not available). The better solution is to install the missing CA certificates, but this process depends on your environment, so I cannot provide instructions here.
The wiki says, the login captcha is meant to prevent "Bruteforcing the passwords". In this case, I think, it is the wrong tool for the job. If someone makes an effort to get a password using brute force on the login form, the captcha won't stop him. It looks rather weak, so even standard OCR software should be able to read the text without applying some special algorithms. If you really want to prevent brute force attacks, you should deny the login (based on the IP address) every twenty failed attempts in a row for five minutes or something similar. As brute force involves testing a huge number of passwords, an attacker does not get very far with 240 passwords per hour, but a user who has forgotten his password and tries to recover it, might eventually succeed.
you think its likely that they easily bypass via own openid provider?
I think, it is more likely that someone breaks the captcha. As noted above, it is not very strong, so breaking it does not require huge efforts. In addition, a captcha nowadays is a common obstacle, so attackers are already prepared to break it. OpenID, on the other hand, still is rather unknown, and I can't yet imagine an attacker, that is prepared to use it, for example by operating a provider that successfully authenticates every request to simulate a huge number of users.
maybe options could be added to captcha ext
a. disable for openId registrations
b. disable for openId log ins....
That's the question. Should the antispam extension detect the presence of the OpenID extension, ask the OpenID extension if an OpenID request was received and in that case disable itself, or should the OpenID extension detect the presence of the antispam extension, and use its hooks to bypass the captcha? In my opinion, the latter option makes more sense (given that the hooks are at the right spots), but at the moment I won't implement it. Time is always short, so I have to concentrate on the important things, and as I personally would not use the antispam extension in the current state (weak captcha, captcha on login form), it can't be considered important. However, patches are welcome.
Edit: But I made one small change: My code removed too much markup responsible for displaying "required" at form fields, so for example the captcha input field does not look like it should. The new code will remove it only from the necessary fields. The change has already been comitted to the Git repository and will be in the next release.
Adds CAPTCHA to the register, login and guest post form.
A captcha on the login form? Isn't that just overkill? In my opinion, this is as good as saying "I don't want anybody to use this forum". Users might be used to enter a captcha once when registering, but every time they want to log in?
What benefit does this provide anyway? To log in, you need to have an account. If you have an account, you have at least once successfully entered the captcha on the registration form. And that means, that you are either human or have successfully broken the algorithm used by the captcha. In both cases, solving another captcha is useless.
No I just mentioned it because it prolongs the registration process.
I guess depending on the openid provider it would be less entering of information - with versign quite a few parameters can be selected/entered....
Under ideal circumstances, the registration process is completed without any further user interaction after entering the OpenID. Ideal means:
OP provides at least username and e-mail address via Simple Registration or Attribute Exchange Extension
PunBB does not complain about either of them (username already taken etc.)
you don't have to enter a captcha 
I noticed the captcha too, but I think it is ok the way it is. If you want your users to enter a captcha, they should do so when using an OpenID too (otherwise a spammer might just use his own OpenID provider to bypass the captcha). From the viewpoint of the OpenID extension, the captcha is just some other error that needs to be fixed by the user (as, for example, a duplicate user name). Or did you notice any problems when using OpenID and captcha?
Which extension provides the captcha functionality?
Can you try and log in with an openId at http://punbb-b.keydogbb.info
I've tried with mine and keep getting redirected to claimid website and "unable to log in"
What exactly did you enter as your OpenID? As you might have seen, I was able to successfully log in using 'openid.claimid.com/punbb'.
There were however some flaws when trying to log in with disabled cookies. The default PunBB error message 'You appear to have logged in successfully, however a cookie has not been set.' should be displayed, but instead a misleading message was displayed or no message at all. This has been fixed in 1.0.3.
PHP: 5.2.8, MySQL5, Linux server.
This is strange. You didn't compile PHP yourself and somehow managed to disable SPL, did you? Google finds almost no results when searching for the error message, so it does not seem to be a common problem.
Are you able to use other SPL functionality such as this script? If so, please post the output.
<pre>
<?php
var_dump(spl_classes());
?>
</pre>Edit: Ok, I did some further research, and there seem to be some distributions that disable SPL by default, for example Gentoo. Which distribution do you use?
You can check if SPL is enabled using the output of phpinfo(), there should be a section labelled 'SPL' stating that it is enabled and listing the available interfaces and classes.
Which version of PHP do you use?
The InvalidArgumentException is part of the Standard PHP Library which "is available and compiled by default in PHP 5.0.0". The InvalidArgumentException itself is available since 5.1. Other features of the extension require at least PHP 5.2, so this is the minimum version you should use.
All the bugs that I am aware of are fixed (except those noted in the first post, but nothing critical there). Though I can not guarantee that there are no more, I think it is ready to use. If you still encounter any problems, I'll try to fix it asap.
There was a potential problem if you were using table name prefixes. In some queries, the prefix was not added correctly. This has been fixed in 1.0.2. Please try to reproduce the problem using this version.
Thanks for your testing so far. Manually creating the table (and the other things mentioned above) might give us a clue about the cause of the problem. If you can't create the table manually, the forum probably can't too, and I could investigate why the error message is missing.
Anyway, I've now installed the old PunBB 1.3.2 using a MySQL 5.0.51a database with mysqli extension and I was able to install the extension without any problems. My server is not completly identical to your setup, but relatively close (I'm using Ubuntu, not FreeBSD, no accelerator, and my software is slightly older: PHP 5.2.4 instead of 5.2.9, MySQL 5.0 instead of 5.1). I have further verified that all hooks used by my extension are present in the 1.3.2 source code, so if there are no other big changes in the surrounding code, the extension should work with 1.3.2 too (I was able to successfully log in using an OpenID, but I have not tested all other functionality).
And as a last test, I denied the PunBB database user the right to create tables, so the subsequent installation attempt failed saying:
An error was encountered
The error occurred on line 351 in /[...]/include/dblayer/mysqli.php
Database reported: CREATE command denied to user 'punbb'@'localhost' for table 'openid_map' (Errno: 1142).
So, error messages seem to be ok.
What did you try so far to solve the problem? Did you manually create the missing table? Have you checked if the installation code is executed using the method I described above?
If the webserver user is the owner of that directory, yes. Otherwise 777 should help. If you do not know who owns that directory or under which user your webserver runs, simply try to log in using OpenID. If it works, everything is ok, otherwise try to change the access rights.
The message indicates that the userid-to-openid mapping table was not created. There are two possible reasons, both seeming unlikely:
1. Your PunBB did not execute the code in the install section of the manifest.xml. This is unlikely, because according to PunBB SVN version 1.3.2 already supported the install section. You can try if this is the reason by removing the oid_store directory in the extension directory and perform the installation again. If the installation code is actually executed, either the oid_store directory should be available again or you should see an error message saying that it could not be created.
2. The SQL query used to create the table failed in your MySQL database, but worked with my PostgreSQL database. This is unlikely because if the query fails you should see an error message too, and because the SQL query works with my MySQL 5.0 database.
You can create the table manually using this command (which is the exact query generated by PunBB's mysqli database layer):
CREATE TABLE openid_map ( openid VARCHAR(255) NOT NULL, userid INT(10) UNSIGNED NOT NULL, PRIMARY KEY (openid) ) ENGINE = MyISAM CHARACTER SET utf8Hello,
I'm pleased to announce my OpenID extension for PunBB, as requested in http://punbb.informer.com/forums/topic/ … -support/. It was developed as part of my bachelor thesis. It makes use of JanRain's PHP OpenID Library 2.1.3 from http://www.openidenabled.com. Though the library itself claims to support PHP 4, the extension requires PHP 5.2 due to heavy use of object-oriented features. Because of the library being backwards compatible, it triggers some warnings when using PHP 5. I have fixed those in the library shipping with the extension; otherwise, it's unchanged.
Features
login using OpenID (more than one OpenID per account is possible, traditional password-based login too)
registration using OpenID (both SReg and AX are supported to request attributes)
add/remove OpenIDs to/from existing accounts
authentication using OpenID to change password/e-mail address (instead of entering old password)
update profile information using OpenID (again, using SReg or AX)
list of users OpenIDs in profile (private information)
administration: user search includes OpenIDs in results
administration: search for OpenIDs
English and German localisation
Future ideas
OpenID-only accounts: flag indicating if a valid password has been set, if not, hide all password input fields
sorting of OpenIDs: allow user to set order or select default OpenID to preselect
Known bugs/limitations
An attacker may learn which OpenIDs are registered and which not: a) upon login only for unregistered OpenIDs attribute requests are send, b) when adding an additional OpenID to an account, before authenticating it is first checked, if it is already registered; should this behaviour be changed to not leak any information?
CSRF form: the confirmation form provided by PunBB does not work for OpenID requests (*). However, it should never be displayed as a custom csrf token is added to each request and checked accordingly.
Timezone is not requested using AX extension: Might as well be an OP bug, as it could only be confirmed for myopenid.com, the only OP I'm aware of that supports the AX extension. Can you confirm this behaviour using another provider or do you know of any other provider supporting AX?
(*) This seems to be a rather complex issue. OPs may choose GET or POST when answering a request. When choosing POST, the csrf token that PunBB expects is (obviously) missing, so the csrf confirmation form is displayed. When PunBB generates the csrf confirmation form, it produces one hidden field per received POST parameter. But it has to add two more fields, e.g. for the csrf token. These additional fields confuse the security mechanisms of the OpenID library and the request is denied. This is most probably a library limitation and I can see no possibility for a workaround. The library uses php://input to read POST parameters, so there is no chance to remove the additional parameters before making library calls.
Tested using
PunBB 1.3, 1.3.2, 1.3.4
MySQL 5.0, 5.1
PostgreSQL 8.3
PHP 5.2
Tested providers
PHPMyID
claimid.com
meinguter.name
myid.net
myopenid.com
openid.claimid.com
pip.verisignlabs.com
xlogon.net
Changes
1.1.0: login using XRIs, changes to data format in database, some simplified code
1.0.4: tested compatibility with PunBB 1.3.0, some minor bugs fixed
1.0.3: fixed no/wrong error message displayed when trying to log in with cookies disabled
1.0.2: fixed adding of table name prefixes
1.0.1: two minor bugs managed to hide on my todo list, fixed in this version
1.0.0: first public release
Download
Download: https://dev.asdn.eu/projects/punbb-openid/files
Git-Repository: git://git.asdn.eu/punbb-openid
Please be aware that this is the first public release of this extension. Though I have tested everything I could think of, there may still be some bugs around, including bugs affecting the security, i.e. permitting someone to login without valid authentication etc. Feel free to use it and please report all problems you may encounter.
Regards,
Alexander
Pages 1
PunBB Forums → Posts by webmeister
Powered by PunBB, supported by Informer Technologies, Inc.