OJS OCS OMP OHS

You are viewing the PKP Support Forum | PKP Home Wiki



[RELEASE] User registration process validated by mail

Are you responsible for making OJS work -- installing, upgrading, migrating or troubleshooting? Do you think you've found a bug? Post in this forum.

Moderators: jmacgreg, btbell, michael, bdgregg, barbarah, asmecher

Forum rules
What to do if you have a technical problem with OJS:

1. Search the forum. You can do this from the Advanced Search Page or from our Google Custom Search, which will search the entire PKP site. If you are encountering an error, we especially recommend searching the forum for said error.

2. Check the FAQ to see if your question or error has already been resolved.

3. Post a question, but please, only after trying the above two solutions. If it's a workflow or usability question you should probably post to the OJS Editorial Support and Discussion subforum; if you have a development question, try the OJS Development subforum.

[RELEASE] User registration process validated by mail

Postby mbria » Mon Nov 20, 2006 11:16 am

Hi all,

We are finishing our magazine and is close to be open, so thanks a lot to the OJS team to free this wonderful pice of software, that we all expect will make our life easier. :-)

At this momment, we are making real test in our normal day situations and it's amazing but your development fits quite perfecly with our way of working. Thanks again.

Any case, we found a little nuance, that looks insignificant, but we belive could be the focus of errors.

Imagine that a reviewer adds him/herself to the OJS, but writes incorrectly his/her mail. What will happen?

They will be able to work with the platform with their user and pass, but they won't recive ANY notifications and we won't have a way to contact them.

We reviewed OJS but looks like the registration process isn't the "normal one"... and by normal I want to say the most common.

Normally in most websites your register yourself, then you recive a mail with a link to the magazine and after this you click on this link to activate your user.

As far as I know, OJS does this process in a different way: User is registered and directly accepted, and after this... if the mail is the correct one, they recive a mail with their login information (user/pass).

Anybody knows if there any way to revert this OJS process to the "normal" one?

We belive mail validation is mandatory for the notifications that are extremally important to ensure the workflow will be accomplished.

Thanks a lot in advance,

m.
Last edited by mbria on Mon Jan 22, 2007 4:56 am, edited 3 times in total.
mbria
 
Posts: 316
Joined: Wed Dec 14, 2005 4:15 am

Postby asmecher » Mon Nov 20, 2006 1:00 pm

Hi mbria,

That's correct; we don't currently confirm email addresses before creating an account. A validation step might be a feature worth adding. The reason we chose not to include it so far, though, is that many users (particularly authors and reviewers) have little patience with web sites and if they don't understand the validation process or if the validation email doesn't appear immediately they will often give up.

What I'd suggest doing is enabling the "envelope sender" option in config.inc.php; this will cause a new field to appear on setup, page 1, where you can enter a contact email address. This address will be used as the "bounce" address for all outgoing journal emails. If, for example, a Reviewer's email address is incorrect, the bounce message will go to your team and you'll be able to correct or remove the reviewer as necessary.

Regards,
Alec Smecher
Open Journal Systems Team
asmecher
 
Posts: 9076
Joined: Wed Aug 10, 2005 12:56 pm

May be in former versions?

Postby mbria » Wed Nov 22, 2006 8:46 am

Dear asmecher,

As always, thanks a lot for your fast answer. OJS won't just a good pice of software without your support and this community, but you all and specially you make OJS excellent.

Two nuances:

a) I compared it in different ways, but I didn't notice any difference in the Config>Page1 when I enabled the "envelope sender". May be is something that is deprecated in last OJS version and is always enabled? Any case, under sender's signature I found a box where "returned mails" are sent and it did the job.

b) My fellows aren't compleatly happy with this solution because (and I didn't comment this in my former mail) they are thinking in enable the "comment" feature and "unvalidated" users (in other words, users without a valid mail) will be able to comment. Any suggestion for this issue? Any change planed in next versions?

Thanks a lot for your help,

m.
mbria
 
Posts: 316
Joined: Wed Dec 14, 2005 4:15 am

Postby asmecher » Wed Nov 22, 2006 10:17 am

Hi mbria,

Thanks! We (and I) try our best to build an active community, and this forum is a big part of it. The feedback we get here provides a major part of OJS's development direction.

a) When you enable the allow_envelope_sender option, the "Bounce Address" option on Setup page 1 will become active. (It's displayed regardless, but you can't enter a value until allow_envelope_sender is enabled in config.inc.php.) Sounds like you found it.

b) The development version of OJS supports Captcha tests for user registration and anonymous comments. This won't guarantee that you have a valid email address, but if your concern is about spammers, this should provide at least a partial solution. I've successfully back-ported this into OJS 2.1.1 releases, so if it's a critical feature for you, I can provide instructions.

In any case, I'll bring up the email validation suggestion with the team; it certainly won't be part of the next release, but we may decide to include it in the future.

Regards,
Alec Smecher
Open Journal Systems Team
asmecher
 
Posts: 9076
Joined: Wed Aug 10, 2005 12:56 pm

Best approach?

Postby mbria » Mon Dec 04, 2006 3:54 am

Thanks! We (and I) try our best to build an active community...

No doubt you all succed on it and I'm (we) are the ones to be thankfull.
OJS is becoming an extremally useful development and I must say that none of the questions were left without feedback.

a) When you enable the allow_envelope_sender option, the "Bounce Address" option on Setup page 1 will become active.

Yes, I found it, but I was reporting that this field is aways enabled (at least with my OJS 2.1.1 and Firefox 1.5), nevermind how I set the allow_envelope_sender variable. Probably it's just my installation, so don't worry about it.

b) The development version of OJS supports Captcha tests for user registration and anonymous comments. This won't guarantee that you have a valid email address, but if your concern is about spammers, this should provide at least a partial solution. I've successfully back-ported this into OJS 2.1.1 releases, so if it's a critical feature for you, I can provide instructions.
In any case, I'll bring up the email validation suggestion with the team; it certainly won't be part of the next release, but we may decide to include it in the future.


Thanks asmecher. Captcha will be a nice feature but I can wait util it will be officially released. Please, let me know if this requirement is finally accepted.

I reported all this to my fellows, and they answered that it's something mandatory for them to ensure (at least) the users' and commenters' emails before they open the magazine, so looks like I will need to find a an alternative solution. :-)

As far as I'm the only one in a hurry... I will need to code this feature by by own (yes, you all must be affraid. I'm the worst coder in the world).

So any clue about which one could be the best approach to develop a kind of "traditional autentication" for OJS?

I though in a couple of solutions:
    1) Patch (also called "dirty hack" :-P): Review your code and include some hacks in the authentification process, as well as a new attribute in the DB schema.
    2) New Authorization plugin: The new authorization workflow will need some new logic and a new table (to avoid changing OJS schema and able to store the "still not accepted users"). Valid users will be transfered to the original OJS users' table.

Seams quite obvius that second choice is cleaner and nicer with OJS (and probably LDAP plugin could be a good example to follow), but I'm unsure about which one will take more time, if I can find further documentation or if I missed a third or forth approach to develop this feature as my fellows request.

Hummm... long mail again. Sorry for this. :oops:

Thanks a lot in advance for your unvaluable help,

m.
Last edited by mbria on Mon Dec 04, 2006 4:47 am, edited 1 time in total.
mbria
 
Posts: 316
Joined: Wed Dec 14, 2005 4:15 am

You were right...

Postby mbria » Mon Dec 04, 2006 4:15 am

a) When you enable the allow_envelope_sender option, the "Bounce Address" option on Setup page 1 will become active.

Yes, I found it, but I was reporting that this field is aways enabled (at least with my OJS 2.1.1 and Firefox 1.5), nevermind how I set the allow_envelope_sender variable. Probably it's just my installation, so don't worry about it.


Now I reviewed this again and you are compleatly right. The field is disabled... it's just that my CSS don't show much differences between enabled and disabled inputs so I didn't noticed it until I clic over it.

Once again, but now with a clear explanation: nothing to worry about.
mbria
 
Posts: 316
Joined: Wed Dec 14, 2005 4:15 am

How to enable allow_envelope_sender

Postby msaghaei » Tue Dec 12, 2006 1:53 am

Hi Alec

We have lots of wrong email addresses which sometimes causes real problems to us and our user. (e.g. an author only notified by phone, 4 months after rejection of her paper, because she had a single character typo in her email address)
I enabled the allow_envelope_sender option in the config file, but still the textbox for undeliverable email in setup step 1 was disabled. Clearing the data and template caches was not effective. Perhaps additional server configuration may be required. I searched the documentations and this forum to find how can our linux server admin can configure the server to make this option working, but find nothing. Please tell me which setting or configuration should be set in the server to allow_envelope_sender.

Finally I believe, a user as an author or reviewer (but not necessarily as a reader) must tolerate some additional acctions to validate his or her email address through a validation mechanism. May be it is necessary to have an enable/disable option in config file to control this behaviour according to the site needs.

Regards,
Mahmood Saghaei
msaghaei
 
Posts: 119
Joined: Sun Jan 08, 2006 1:01 pm

Postby asmecher » Tue Dec 12, 2006 12:36 pm

Hi Mahmood,

Yes, we've had several requests for an email validation step in the user registration process. This process already causes enough confusion in the password reset process (which has a validation step), but the benefits may outweigh the added complexity. We likely won't have time to include this in the next release, but it'll certainly be a priority for the following one, and we may provide a patch to back-port the feature into this release.

The bounce address field in Journal Setup, step 1 should only depend on the value of the allow_envelope_sender setting. The configuration file isn't cached. Make sure it's not set twice in the configuration file and check the syntax to make sure it's correct; I'm not sure what else could be causing this field to stay disabled.

Regards,
Alec Smecher
Open Journal Systems Team
---
Don't miss the First International PKP Scholarly Publishing Conference
July 11 - 13, 2007, Vancouver, BC, Canada
http://ocs.sfu.ca/pkp2007/
asmecher
 
Posts: 9076
Joined: Wed Aug 10, 2005 12:56 pm

Postby msaghaei » Tue Dec 12, 2006 10:09 pm

Hi Alec

It works now! :D
I must confess that it is wonderful and it is more than enough for our purpose. I think it is a necessary functionality for a journal system to hold track of returned email and I hope this functionality will not be omitted in future versions or exchanged with a simple single use only email validation (although it is also necessary).

Anyhow where can I find some info on CAPTCHA ?

Regards,

Mahmood
msaghaei
 
Posts: 119
Joined: Sun Jan 08, 2006 1:01 pm

Postby asmecher » Wed Dec 13, 2006 11:24 am

Hi Mahmood,

Email validation or not, we'll certainly keep the envelope sender feature in place, and if we do implement email validation, it'll be an optional process.

CAPTCHA support is in the CVS version of OJS, and I've successfully back-ported it into OJS 2.1.1 installations, but it's an involved process; the bugzilla entry is at http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=2350 with a list of modified files. If you look at the commit history for each file at http://pkp.sfu.ca/cvs/cvsweb.cgi/ojs2, you'll find the bug number (#2350) entered beside Captcha-related commits. Unfortunately, we can't provide assistance with back-porting, but if you have some PHP expertise, that should be enough information to get started. Currently, OJS supports CAPTCHA tests on user registration and on article comment postings.

Regards,
Alec Smecher
Open Journal Systems Team
---
Don't miss the First International PKP Scholarly Publishing Conference
July 11 - 13, 2007, Vancouver, BC, Canada
http://ocs.sfu.ca/pkp2007/
asmecher
 
Posts: 9076
Joined: Wed Aug 10, 2005 12:56 pm

No answer?

Postby mbria » Mon Dec 18, 2006 5:26 am

Dear all,

Any answer about the second part of my post of on "Mon Dec 04, 2006" titled "Best approach". ?

Probably it was missed in the conversation thread, so I just hope you don't mind if I repost it again:

So any clue about which one could be the best approach to develop a kind of "traditional authentication" for OJS?

I though in a couple of solutions:

1) Patch (also called "dirty hack" Razz): Review your code and include some hacks in the authentication process, as well as a new attribute in the DB schema.

2) New Authorization plugin: The new authorization workflow will need some new logic and a new table (to avoid changing OJS schema and able to store the "still not accepted users"). Valid users will be transfered to the original OJS users' table.


Seams quite obvious that second choice is cleaner and nicer with OJS (and probably LDAP plugin could be a good example to follow), but I'm unsure about which one will take more time, if I can find further documentation or if I missed a third or forth approach to develop this feature as my fellows request.


Again, thanks a lot in advance, :-)

m.
mbria
 
Posts: 316
Joined: Wed Dec 14, 2005 4:15 am

Postby asmecher » Mon Dec 18, 2006 10:31 am

Hi mbria,

I think this facility would be best implemented as an addition to the codebase (i.e. a patch) since it would be well-suited for distribution with OJS and this will save you some of the contortions needed for plugins. There is a facility included in OJS called "access keys" that should provide some of the needed functionality; this is used, for example, to support "one-click" reviewer access, which bypasses the regular login process using a single-use access key as part of the URL.

If you do decide to go with a plugin approach, I'd suggest using a generic plugin. Authentication plugins are designed for a specific task (logging in against an external user database) that doesn't suit your task.

Regards,
Alec Smecher
Open Journal Systems Team
---
Don't miss the First International PKP Scholarly Publishing Conference
July 11 - 13, 2007, Vancouver, BC, Canada
http://ocs.sfu.ca/pkp2007/
asmecher
 
Posts: 9076
Joined: Wed Aug 10, 2005 12:56 pm

Some doubts

Postby mbria » Thu Jan 11, 2007 5:19 am

Hi,

I'm following asmecher suggestion and I'm working on a patch to develop the requirement I formerly expressed.

Seams to me that the natural place for this new feature is /manager/setup/2 so I patched JournalSetupStep2Form.inc.php (simply adding a new attrib), the respective template and lang and everything worked perfectly... but now is time to hack the registration process and I have a couple of doubts, that I list below:
    Hack design: Minimum changes is always the best so I was thinking in letting OJS work as now and do the "new user registration job", BUT (only when my hack is activated) user is initially "disabled". After OJS registering I need to create the token, send the confirmation mail and wait for an answer. On user's class, a new "verb" will be accepted, with the right user's id and token params to finally activate it.
    Sounds it find with you?
    Where to store user's tokens? If the new registration process will be "User submits form -> User answers email -> OJS activate user account" a token for each user (or a quite random unique user ID) is required, but... which is the best place to store this data? I think I have 3 choices (from best to worst, in my opinion):

    a) Store it at table "users" on the existing attrib "auth_id": What is this attrib for? Looks like was created to be a unique user id, but is not filled yet. If now or in future OJS will maintain this data I won't need to do and it will same me some development time.

    b) Store it at table "user_settings": And here the question is "what is this table for?". Once again I "suspect" this table was created to store user's extra information, and a nice management class is also distributed but I'm not full sure if this will be best place.

    c) Update OJS schema: This is the simplest solution, but former ones are cleaner.

    What do you think?

Finally (although may be is early to ask it), if code is clean, follow OJS standards and only does it simple tasks... ¿does OJS team accept "core" contributions to be included in future releases?

Thanks a lot for your help,

m.
mbria
 
Posts: 316
Joined: Wed Dec 14, 2005 4:15 am

Postby asmecher » Thu Jan 11, 2007 10:15 am

Hi mbria,

The access_keys table and related classes (e.g. classes/security/AccessKeyManager.inc.php) should provide the token management functions you're looking for. Let me know if you have any questions about this.

We'd be delighted to accept this for inclusion in a future release -- see http://pkp.sfu.ca/support/forum/viewtopic.php?t=439 for development guidelines. When you're ready, please send us your code as a unified patch (e.g. generated using the -u option to the diff tool) either against a recent CVS checkout or against the last stable release.

Regards,
Alec Smecher
Open Journal Systems Team
---
Don't miss the First International PKP Scholarly Publishing Conference
July 11 - 13, 2007, Vancouver, BC, Canada
http://ocs.sfu.ca/pkp2007/
asmecher
 
Posts: 9076
Joined: Wed Aug 10, 2005 12:56 pm

Thanks !!

Postby mbria » Thu Jan 11, 2007 11:07 am

Thanks Alec for the fast and clear answer.

What do you think about the "hack design"?

From your background knowledge about OJS... is RegistrationHandler the best place to fit the hack or you have a better suggestion?

Cheers,

m.
mbria
 
Posts: 316
Joined: Wed Dec 14, 2005 4:15 am

Next

Return to OJS Technical Support

Who is online

Users browsing this forum: Yahoo [Bot] and 6 guests