Create links in ticket emails that auto login and go to the ticket

[khoffman]

There has been a lot of talk on the forums about how to have links in auto respond ticket emails to automatically login AND show the ticket. This can't be accomplished via direct URLs. There's even a ticket bugged for it: http://bugs.kayako.net/?do=details&id=345

But I will show you how to do it today!

Overview: modify login form (in navbar template) to populate email address and password based on parameters in the get URL (using the undocumented $_TPL template variable). Then, have some javascript that automatically submits the form if username and password are not blank. Finally, modify email templates to add email / password to URL for ticket.

How to do it:

1. Modify login form (in navbar template)
   
   Login as in /admin, go to template, and edit General->navbar template.
   Delete everything between

   <!-- BEGIN LOGIN BOX -->

   and

   <!-- END LOGIN BOX -->

   and replace it with the following:
   
   

   					<!-- BEGIN LOGIN BOX -->
   					  <tr class="tcat">
   						<td width="1" align="left"><img src="<{$themepath}>space.gif" width="1" height="21"></td>
   						<td width="1" align="left"><img src="<{$themepath}>blockarrow.gif" width="8" height="8"></td>
   						<td valign="middle" align="left">&nbsp;<span class="smalltext"><strong><font color="#FFFFFF"><{$language[login]}></font></strong></span></td>
   						<td align="right" width="130"><span class="smalltext"><{if $loginsharemodule != 1}>&nbsp;<{else}><a href="index.php?_m=core&_a=lostpassword" id="white"><{$language[lostpassword]}>&nbsp;</a><{/if}></span></td>
   					  </tr>
   
   					  <tr>
   						<td bgcolor="#F5F5F5" colspan="4"><form name="loginform" action="<{$basepath}>" method="POST"><table width="100%"  border="0" cellspacing="1" cellpadding="2">
   						  <tr>
   							<td width="46%" class="smalltext"><{if $loginsharemodule != 1}><{$language[loginusername]}><{else}><{$language[loginemail]}><{/if}></td>
   
   <{if $_TPL[GET][u_email] != ""}>
   <td width="54%"><input type="text" name="loginemail" class="logintext" value="<{$_TPL[GET][u_email]}>"></td>
   <{else}>
   <td width="54%"><input type="text" name="loginemail" class="logintext" value="<{$cookieloginemail}>"></td>
   <{/if}>
   						  </tr>
   						  <tr>
   							<td class="smalltext"><{$language[loginpassword]}></td>
   
   <{if $_TPL[GET][u_passwd] != ""}>
   <td><input type="password" name="loginpassword" class="loginpassword" value="<{$_TPL[GET][u_passwd]}>"></td>
   <{else}>
   <td><input type="password" name="loginpassword" class="loginpassword" value="<{$cookieloginpassword}>"></td>
   <{/if}>
   
   							</tr>
   						  <tr>
   							<td class="smalltext"><{$language[loginrememberme]}></td>
   
   <{if $_TPL[GET][u_passwd] != ""}>
   <td><input type="checkbox" name="rememberme" value="1" checked>
   <{else}>
   <td><input type="checkbox" name="rememberme" value="1"<{if $cookierememberme == 1}> checked<{/if}>>
   <{/if}>
   
   						  </tr>
   						  <tr>
   							<td class="smalltext">&nbsp;</td>
   							<td><input type="submit" name="Submit2" value="<{$language[login]}>" class="yellowbutton">                          </td>
   						  </tr>
   						</table><input type="hidden" name="_m" value="core"><input type="hidden" name="_a" value="login"><input type="hidden" name="querystring" value="<{$querystring}>"></form>
   <{if $_TPL[GET][u_login] == "1" && !($_TPL[GET][loginresult] < 0) }>
   						<script language="JavaScript"><!--
   if (document.loginform && document.loginform.submit && document.loginform.loginemail && document.loginform.loginpassword){
   	if (document.loginform.loginemail.value.length > 0 && document.loginform.loginpassword.value.length > 0){
   		document.loginform.submit();
   	}
   }
   						//--></script>
   <{else}>
   						<script language="Javascript">
   						document.loginform.loginemail.focus();
   						</script>
   <{/if}>
   						</td>
   					  </tr>
   					  <!-- END LOGIN BOX -->

2. Modify auto respond ticket template (Tickets->email_autoresponder)
   
   Find the line in the template that looks like:
   
   

   <{$language[arsubfooter]}><a href="<{$swiftpath}>index.php?_m=tickets&_a=viewticket&ticketid=<{$ticket[ticketid]}>"><{$swiftpath}></a><BR><{if $settings[u_sendpw] == 1 && $user[userpasswordtxt] != "" && $user[loginapi_moduleid] == 1}>

   and replace it with
   
   

   <{$language[arsubfooter]}><{$swiftpath}>index.php?_m=tickets&_a=viewticket&ticketid=<{$ticket[ticketid]}>&u_email=<{ urlencode value=$ticket[email]}>&u_passwd=<{urlencode value=$user[userpasswordtxt] }>&u_login=1&group=<{$ticket[tgroup]}><{if $settings[u_sendpw] == 1 && $user[userpasswordtxt] != "" && $user[loginapi_moduleid] == 1}>

   Notice that I added u_email=(email)&u_passwd=(password)&u_login=1 to the URL associated with the ticket. Now when the user clicks that link it will open their web browser, automatically log them in, and then display the ticket!
   
3. Modify other ticket email templates
   
   There are several other templates for ticket emails: email_autoclose, email_staffnewticket, email_staffreply.
   
   It is very handy to add links to these HTML templates to allow the user to click and instantly see their ticket (with auto login).
   
   However, for these templates we cannot add the u_passwd URL parameter -- that needs to be filled in by their cookie! That's because the $user[userpasswordtxt] variable is not populated when these templates execute.
   
   So add something like this to these templates:
   
   

   <a href="<{$swiftpath}>?_m=tickets&_a=viewticket&ticketid=<{$ticket[ticketid]}>&u_email=<{urlencode value=$ticket[email] }>&u_login=1">[Ticket Status]</a>

   For the email_staffforward template it does not make sense to add this, because the recipient will NOT be the user of the ticket. So instead use this for the email_staffforward template:
   
   

   <a href="<{$swiftpath}>?_m=tickets&_a=viewticket&ticketid=<{$ticket[ticketid]}>">[Ticket Details]</a><BR>

   (I like to add it right before the

   </fieldset>

   )
   

IMPORTANT: Remember to clear all files in your cache directory after you modify your template files or you won't see the changes.

[eger]

This is a great idea. I hope the team will implement their own version of this into the system. It would definitely be an excellent feature to have links that display tickets without having to log in.

I think it may be more secure if the ticket had a hash that was sent in the link and it would allow a reply and view of the ticket. But wouldn't actually log in or send a password in plaintext (since you might not be using SSL).

[netFusion]

Originally Posted by eger

This is a great idea. I hope the team will implement their own version of this into the system. It would definitely be an excellent feature to have links that display tickets without having to log in.

I think it may be more secure if the ticket had a hash that was sent in the link and it would allow a reply and view of the ticket. But wouldn't actually log in or send a password in plaintext (since you might not be using SSL).

I agree that this is great! Khoffman, thank you VERY MUCH for figuring this out and sharing!

As far as security goes, how secure an autoresponder is really is not a big concern to me. I figure, the client created the ticket from his or her original email. If it is my system sending the ticket to that user, then it's ok for them to click on the link to come back directly to their ticket.

If the user account and ticket were created by a spam ticket or a bogus user, I really don't care if the spam sender receives a direct link to the ticket in the message or not since I'm just going to delete the ticket anyway.

If someone has hacked a client's email account and is intercepting the client's messages which originate from my system, I really don't care again. They could see the email from my SupportSuite, then go to my support login page and use the feature to email themselves the forgotten password anyway, since they are already intercepting the email from the client's email server.

Agreed that the client will definitely care that his or her emails are being intercepted. But not having the link embeded in the email does not make my system any more secure... It just makes it a couple more steps the offender has to perform if they really want to see me telling my client how to fix their problem.

My two and a half cents worth...

[KB1]

I agree strongly that it would be a great idea for this to be implemented within Kayako as a standard. Come-on lets see it in the next build. There is nothing worse for the customer than faffing about looking for that first e-mail.

[User Name]

Thanks! It works perfectly!

Can you make one for staff to autologin, too?

[Digital Mayhem]

okay I did that and tested it and gives me the link which works but the link isn't clickable so you have to highlight and copy and paste it into a browser window.

[AKL-MFCU]

I only have one concern and i haven't modified it to try it, but is it referencing the username and password into the url or is it attempting to use other credentials to log in? Only reason i ask is because as a financial institution, we can't have anything visible ever pertaining to a username and password in any e-mails.

[ericpj]

I seem to be having trouble getting this to work with new random email addresses sending requests in.

Is there a way to get the system to generate a password for the new email address and send that in the reply?

I have the Settings -> User Registration -> Send Password in Auto Responder Message ... set to Yes

any ideas?

Thanks!

[netFusion]

Originally Posted by AKL-MFCU

I only have one concern and i haven't modified it to try it, but is it referencing the username and password into the url or is it attempting to use other credentials to log in? Only reason i ask is because as a financial institution, we can't have anything visible ever pertaining to a username and password in any e-mails.

You have a bit more of a difficult task then. You will have to disable the auto-responders and the ability for the client to email themselves their forgotten passwords. They can both send the user his/her login name and password.

The only way I can think of for you to never have to send your client an email with their login name and password would be for you to manually pre-register all of your clients and provide them with the information offline. Then disable the autoresponders and go in and take out the code that allows them to send themselves their login info when they forget it.

[nickm]

Also, has anyone gotten this to work with v.3?

[Digital Mayhem]

I had it working in version 3.00.80 but once I upgraded to 3.00.90 it stopped working. Now the clients all get "invalid username or password" error message.

[tm2000]

I've got it working on 3.00.90... New Install though.

Question, I can't get the Link to show us as clickable.. on the autoreponder... what code am I missing?

Here is the template paste:

<BR>
<{$language[arsubfooter]}><{$swiftpath}>index.php?_m=tickets&_a=viewticket &ticketid=<{$ticket[ticketid]}>&u_email=<{ urlencode value=$ticket[email]}>&u_passwd=<{urlencode value=$user[userpasswordtxt] }>&u_login=1&group=<{$ticket[tgroup]}><{if $settings[u_sendpw] == 1 && $user[userpasswordtxt] != "" && $user[loginapi_moduleid] == 1}>
<BR>

Here is how it comes via HTML email source:

<BR>
You can check the status of or reply to this Ticket online at: http://support.mydomain.com/index.php?_m=tickets&_a=viewticket&ticketid=115&u_ email=test.guyr%40mydomain.com&u_passwd=266e8b5c&u _login=1&group=default<BR>
<BR>

[khoffman]

Some email clients do not automatically make URLs clickable. Just wrap in an <a> tag instead. In my actual implementation I changed my language string arsubfooter to be

"You can check the status of this ticket online by "

(without the quotes) and then changed the above code to:

<BR>
<{$language[arsubfooter]}><a href="<{$swiftpath}>index.php?group=<{$ticket[tgroup]}>&_m=tickets&_a=viewticket&ticketid=<{$ticket[ticketid]}>&u_email=<{urlencode value=$ticket[email]}>&u_passwd=<{urlencode value=$user[userpasswordtxt] }>&u_login=1">
[clicking here]</a> (<{$swiftpath}>)<BR>

[khoffman]

Originally Posted by AKL-MFCU

I only have one concern and i haven't modified it to try it, but is it referencing the username and password into the url or is it attempting to use other credentials to log in? Only reason i ask is because as a financial institution, we can't have anything visible ever pertaining to a username and password in any e-mails.

My approach was to have a completely separate username/password for the help desk and not use a LoginShare module (because of problems mentioned by netFusion other emails also include the username/password).

Instead, I chose to do the following:
* Allow unregistered users to create tickets
* Unregistered users who create tickets are automatically registered
* Unregistered users can create a new ticket via email, and when they do it automatically registers them

Thus, their username/password is completely different than the one they care about. Because the information they would submit to our helpdesk via the ticketing system is not extremely sensitive sending their helpdesk username/password via email for every new ticket was acceptable.

Using the method described in this thread allowed the separate username/password to be as transparent as possible. Some users may not even realize they have a separate login (or even a helpdesk login at all) because they can always click to login.

I think that using LoginShare to tie into any system with sensitive usernames/passwords is a bad idea, because AFAIK LoginShare caches the username/password they enter in the MySQL database, and the password is in plain text! So if some hacker (or insider turned bad) got read-only access to the SupportSuite DB they would see all of the sensitive passwords that LoginShare cached. (This allows SupportSuite to send user their actual password if they forget it. Personally I think there should be an option to store the password in MD5/SHA1/SHA256 + salt in DB and if the user forgets their password to randomly generate a new one -- this is much more secure. Hence my decision to not use LoginShare.)

[AKL-MFCU]

we searched the tables as a security measure when using ldap configuration to authenticate and the passwords are encrypted in some form of base coding. I could tell when someone had a similar password because the encryption would be the same, but thats rare you find it. Second, i like that kayako shortens the length of the password if you do the "remember me" option so people cannot just guess the password based on length. (reduced by 12 letter password to about 4).

The main reason i want authentication is because our staff (its internal only) doesn't have time to remember one more pasword. So we are moving most of our programs and anything that we can configure or get custom coded, to just use their windows authentication and set up permissions in AD if we have any security concerns.

It would be nice though if it took the encrypted value in the sql server and passed it through and translated it on the backend, since we could use the html wrap for links it wouldn't matter if it was 5 lines long.