Fastpath - Web Authentication

What does this option actually do? I turned this on and added a password field in the Form UI and no one can use the Webchat. Everyone gets a Authentication failed but the supporters using Spark still get a chat request from the failed authentication. Bug?

Garry

that can only be used if you are restricting fastpath to access by people with a JID on your server, either manually created or LDAP created. If you enable that you most likely need to authenticate with the full JID and password, e.x. Username = johnd@chatserver.domain.com, Password = abc123

It’s weird because the webchat username/password seems to authenticate and the agent using Spark gets a chat request but on the customer webchat side it says Authentication Failed. It seems to be working partially since the agent is actually getting a real request. It’s just that the customer doesn’t get sent to the regular chat window even when the agent accepts the request. We are also using an OD LDAP server.

This is most likely caused by the fact that the request for help is sent prior to the authentication finishing. The authentication is failing so the chat window cannot spawn.

Thanks for the quick responses. I just tried a test by putting in false credentials into the username and password fields and the Agent doesn’t get a request! So it seems to be working somehow, it’s just the customer webchat side doesn’t know it authenticated correctly.

You may be correct I just did that test too. Invaild credentials result in no window, valid credentials do not authenticate and a window pops.

Is there a way for the two to play nice? Can it be done that all you need is a uid/password from LDAP to log into the webchat? That would be amazing.

I’m going through the source files. In which JSP or whatever location does it authenticate the username and password?

Garry

Anyone actually get Web Authentication to work? And how?

I’m still stuck with this as well.

Fixed it!!

The problem was bits after the authentication throwing an exception, which was being misinterpreted as the authentication failing due to incorrect use of the try/catch block.

To solve this, check out the sources from subversion. In webchat/src/java/org/jivesoftware/webchat/actions/ChatStarter.java, apply the following patch:

Index: actions/ChatStarter.java

— actions/ChatStarter.java (revision 12013)
+++ actions/ChatStarter.java (working copy)
@@ -198,23 +198,33 @@
// authentication is required, all users must login
String username = (String)metadata.get(“username”);
String password = (String)metadata.get(“password”);

  •            boolean chatloginok=false;
               try {
                   chatSession.login(username, password);
    
  •                // load user metadata
    
  •                properties = wGroup.getWorkgroupProperties(username + "@" + settings.getServerDomain());
    
  •                metadata.put("name", properties.getFullName());
    
  •                metadata.put("email", properties.getEmail());
    
  •                chatSession.setEmailAddress(properties.getEmail());
    
  •                metadata.remove("password");
    
  •                chatloginok=true;
               }
               catch (Exception e) {
                   try {
    
  •                    WebLog.logError("Authentication failed - ", e);
                       response.sendRedirect("userinfo.jsp?authFailed=true&workgroup=" + workgroup);
                   }
                   catch (IOException redirectException) {
                       WebLog.logError("Error during redirection - ", redirectException);
                   }
               }
    
  •            // load user metadata
    
  •            if (chatloginok) {
    
  •                try {
    
  •                    properties = wGroup.getWorkgroupProperties(username + "@" + settings.getServerDomain());
    
  •                    metadata.put("name", properties.getFullName());
    
  •                    metadata.put("email", properties.getEmail());
    
  •                    chatSession.setEmailAddress(properties.getEmail());
    
  •                    metadata.remove("password");
    
  •                }
    
  •                catch (Exception e) {
    
  •                    WebLog.logError("Error setting up workgroup properties - ", e );
    
  •                }
    
  •            }
           }
           else {
               for (int i = 0; i < 5; i++) {
    

@@ -330,4 +340,4 @@
}

-}
\ No newline at end of file
+}

After building and deploying the chat client with this patch, chat authentication works properly.

If the other bits fail, this will be logged (the actual cause), whereas an incorrect password will still yield “Authentication failed.” as before.

Filed as OF-419 , thanks

Thanks Marc, you’re now my favourite developer. :slight_smile:

Does this patch also apply to the released version of 3.7.0? I am also having this problem with an LDAP integrated OF server running Fastpath service plugin 4.2 and the Webchat on Tomcat 6.0.

If so, could you provide details on how to actually install the patch?

Thanks!

Is there a compiled version with this patch for us non-programmers? Or in the event that there isn’t can someone please provide detailed instructions as to how to compile the .java patch?

Any help would be appreciated. Thanks!

José Carlos

Is there a compiled version with this patch for us non-programmers? Or in the event that there isn’t can someone please provide detailed instructions as to how to compile the .java patch?

Any help would be appreciated. Thanks!

José Carlos

The bug tracking system (http://issues.igniterealtime.org/browse/OF-419) states it’s fixed in 3.7.2, so any version from there on should work.

Marc, thanks for the answer, however I can’t find Openfire version 3.7.2… can you help?

Thanks.

José Carlos

Since I submitted the patch nearly 2 years ago, I haven’t currently got a build environment handy. I suggest joining the group chat in about 50 minutes and asking about the release schedule for 3.7.2, as it might be closer than you think.

I just upgraded to 3.7.2 Beta and the problem persists with authentication in Fastpath Webchat

any thoughts?

Thanks

José Carlos