Hmm, I think you are missing the point. Our customers (the organisations) are
very well-known to us. The individual users within those organisations are not.
We are contractually committed to give support to ANY user from within our
customer's organisations. For some of our customers there are literally
hundreds of users that we serve within a single customer organisation. We would
kill ourselves if we were to set up customer users on a person-by-person basis.
And it would probably infuriate our customers to wait for us to do so every
time.
There's no way that our customers would hand out anything that looks like a
user registry, e.g LDAP or similar. These are well-guarded secrets that cannot
even be offered to the government unless required to by law. Corporations treat
even the usernames that they use internally as well-guarded secrets that are
not to leave the doorstep of the organisation. (the idea is that knowing
internal user names within a corporation moves a potential hacker one step
closer to his target).
This may all sound as if I cannot use your answer. Far from it. I can use the
CAPTCHA idea and will look into it.
Thank you.
Brian
________________________________
From: Gerald Young <[email protected]>
To: "[email protected]" <[email protected]>; User
questions and discussions about OTRS. <[email protected]>
Sent: Tuesday, August 28, 2012 5:57 PM
Subject: Re: [otrs] Restricting the self-registration feature
http://forums.otterhub.org/viewtopic.php?f=60&t=5941 (reCAPTCHA)
http://forums.otterhub.org/viewtopic.php?f=60&t=6586 (Accept customer only
emails as tickets)
or, ddt (don't do that). "our customers should be able to self serve as much as
possible."
"our customers" and "self serve" are contradictory in this sense. If they're
your customers, you should already know who they are and have them as customers
(link to or import from existing data source). They shouldn't have to register
themselves if they're known to you. (Personal opinion). Now, in the case of
(large multinational corporation) this may be a bit difficult to obtain and
sync all the customers who will be able to create tickets with your company,
but on the other hand, if you're that intimate, you may ask to get an ldap
connection for Customer queries. That will be helpful in this case:
1) add/remove users is not up to you
2) password management is customer-side (ldap)
3) customer knows her password is the same as office
4) no registration
5) zero administrative communication when users change
6) list is always uptodate
7) you don't burden your customers with registration
On Tue, Aug 28, 2012 at 11:33 AM, [email protected]
<[email protected]> wrote:
>Maybe I'm thick but I cannot figure this one out:
>
>I really like the self-registration feature. The idea is that our customers
>should be able to self serve as much as possible.
>However at the moment anyone can register and I fear that when we go live
>there will be lots of self-registration attempts by spammers.
>
>In the company I work for the customer organizations are well-known (a dozen
>or so). The users within them are not (several hundreds).
>
>What I would like is that only users (customers) who register with e-mail
>domains that are known to the OTRS system are allowed to self-register on the
>portal.
>Example : We would allow [email protected] to self-register because IKEA is a
>customer of ours and thus "@ikea.com" is a well-known e-mail domain.
>Conversely if [email protected] tries to register he should be rejected.
>(IKEA is not really a customer of ours in real world :-))
>
>Having the above functionality would of course require that OTRS would store a
>list of known e-mail domains for each customer organization.
>
>But, but. There may be other ways to prevent misuse of the self-registration
>feature. Perhaps some functionality that already exist? Any ideas ?
>
>Thx.
>
>
>Brian
>
>
>
>
>
>---------------------------------------------------------------------
>OTRS mailing list: otrs - Webpage: http://otrs.org/
>Archive: http://lists.otrs.org/pipermail/otrs
>To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
