search

igniterealtime / openfire-pade-plugin

A plugin for Openfire that offers web-based unified communications - chat, groupchat, telephone, audio and video conferencing.
Apache License 2.0
58 stars 30 forks source link

Windows NTLM Authentication does not work. #171

Closed cool0707 closed 3 years ago

cool0707 commented 3 years ago

Even if I enable Windows NTLM Authentication, it does not work properly. In lib-jitsi-meet.min.js, it seems to access "/sso/password", but when I access it with a browser, it returns a 404 error.

deleolajide commented 3 years ago

You also need the pade plugin installed to use NTLM authentication

cool0707 commented 3 years ago

Pade pluginis already installed. I found out that it works when the Context Path is set to "/ofmeet", but not when the Context Path is set to "/". Is there any way to enable NTLM authentication with the Context Path set to "/"?

gjaekel commented 3 years ago

I struggled with the same thing. To resolve this poses a challenge: The mechanisms of servlets require that the shortest context path is registered after the longer. But a the moment, there's no support for a defined order at the OpenFire module loader.

In fact, there already is support for a submodule relationship, but this will require the parent module (as a must, but not as a depend). I already had have a discussion about this with @deleolajide (see #154).

What's the core reason that you want to have OFMeet at the root context but not at "/ofmeet" or something like that? For my needs, I have solved this task at my reverse proxy and I may share a set of rewrite rules (Apache, but you may translate for NGinx by need).

deleolajide commented 3 years ago

Looks like we have yet one more reason to merge ofmeet plugin into the pade plugin and create a single unified plugin that controls the loading order of all components (jvb, jicofo, jigasi, freeswitch and pade web services)

gjaekel commented 3 years ago

Or we enhance the OFMeet plugin loader to support hints like "after foo" or "before bar" in plugin.xml. The benefits of unification are a bit shortened by the fact that you have to implement some "privat subcomponent manager", because IMHO on should be able to disable unneeded components.

If we enhance sortPluginDirs a little bit, it's all done: Add a tag similar than parentPlugin, but with no requirement of the parent and no force to use the parent classloader. Of course, this have to be accepted by our "upstream team" (@guusdk ?).

deleolajide commented 3 years ago

The benefits of unification are a bit shortened by the fact that you have to implement some "privat subcomponent manager", because IMHO on should be able to disable unneeded components.

That is already in place. The jvb, jicofo and pade webservices will be mandatory. jigasi and freeswitch are optional and have enable/disable properties

deleolajide commented 3 years ago

Or we enhance the OFMeet plugin loader to support hints like "after foo" or "before bar" in plugin.xml.

This is a a bit of work to the plugin manager in Openfire core. It has been discussed several times before, but nobody has the appetite to do this task.

cool0707 commented 3 years ago

I understand that the problem is due to the loading order of the plugins. Since I am using Openfire only for Pade Meetings (Openfire Meetings?), Root context would have been preferred, but I will consider using a context like "ofmeet". Thanks.

gjaekel commented 3 years ago

Me too, because that's the URL to be used as "server" in the smartphone app Jitsi Meet. No reverse proxy in front?

cool0707 commented 3 years ago

We do not have a reverse proxy because we plan to use it only within the company.

deleolajide commented 3 years ago

This should be fixed with version 1.3.0 - https://github.com/igniterealtime/openfire-pade-plugin/issues/154#issuecomment-750927857