[redzzzzz]

Hello,

First of all, great work. You have potentially saved us plenty of work if we decide on a kayako integration to our client portal.

Perhaps I'm completely off and/or this is a Kayako limitation. However I'm stuck on the following:

In our client portal username is unique and email adres is not. This way users can keep seperated useraccounts if they desire (and they do).

The getSubmittedTickets and getSubmittedTicket do not require the Kayako end-user pass for validation just the API user/pass, correct?

How do I prevent displaying wrong tickets or ticket theft by our users without making all our email adresses unique fields? I need to bind tickets to a username not to an email adres.

Example: our user A changes his e-mail adres 'accidently' to the email adres of user B in our portal profile. This would then trigger updateEmailAddress changing all the user A Kayako e-mail adres to become identical to User B. As a result both User A and B share the same tickets.

Anyone have any suggestions?

[Craig Brass]

Well say if User A and User B both had the same email addresses, logging in as either would show the same ticket list. If you setup updateEmailAddress and User A changed their email address but User B didn't, User A would see all old tickets while User B would see no tickets. It is a limitation of Kayako really.

[redzzzzz]

Hmm.. that is really to bad. We have been working with Kayako seperate from our client portal for several years now, but we are looking into a way to safely integrate them. The email adres as key would be a big loophole and could be easily exploited in my opinion.

Don't know kayako internals very well, but I noticed the 'Full name' field for a user.

Any thoughts on if I could modify the API to check full name instead of email adres and use that as key (instead of the email adres)?

Perhaps I should give up bothering and perhaps abandon Kayako alltogether..

[Craig Brass]

Ohhh yes, I see your point now. Somebody could register and get access to all the tickets. I have never faced this problem before as the systems I integrated with all used email addresses as the login unique field.

Unfortunately, I do not really see any way around it when using an API unless you switch to using email addresses in your other system.