Andrzej Wójcik (Tigase) opened 1 decade ago
|
|
As issue #2083 will be resposible for creating static HTML file containing (I think) the same informations, so this issue would be about serving this static file using HTTP server? What about permissions to access this informations? As I think this would be active by default, I wonder how we would like to protect access to this information? Should we request user login and password and verify credentials as well as if user is listed in server adminitrators list? I think we might do this as access to this information would be available also if accessing using HTTP server fails as we would have static file saved on disk. If so then we may serve this as another module of HTTP API component but it would be available only if HTTP API component would be loaded and configured properly. Is it OK? |
|
Andrzej Wójcik wrote:
Yes, this is just serving static page. It can be a file in a fixed location. Very simple thing to make sure it always works, even if nothing else except HTTP API works in Tigase.
I think that if the server is not configured yet - it is in installation/configuration mode, then access to this page should be unrestricted. But then the page would be very simple, information about our software, and that it is not yet properly installed/configured and a link to the web installer/configurator. Here, instead of having completely open access, we could have some default user: admin/admin instead. But this is the same as open access, so what's the point.... Part of the configuration process would be setting up access to the HTTP API and this page in particular. User should have a choice whether to protect access to this page or not and how he wants to protect it (user name/password, providing access keys, automatically generated access keys, etc...) Of course the configurator can suggest some sensible defaults. Then, once the server is properly configured and runs in a normal mode, access to the page should be set to the level selected by a user during configuration time.
Yes, indeed. I think we should have at least 2 ways to access the HTTP API:
Yes. This makes the HTTP API component a critical part of the Tigase server. We need to make sure it works (responds to the user) even if nothing else works. |
|
Updated due date as I need to delay this to wait for completion of #2083 |
|
Added basic module for presentation static server information file from logs/server-info.html |
|
Handler which will load data from static file is ready. All we need now is code which will create and fill this file with proper informations |
|
What is the default link to get to the startup report? Actually it would be good to get all the recent HTTP API additions and new functions and create a wiki page with some description. We need to create a full installation guide for the new version at some point, but for now some basic information for testing purposes is necessary. |
|
%andrzej.wojcik is java listening on port 80 for this? I saw port in use in the logfiles which is why I want to ask: Can we configure an alternate listening port? |
|
%andrzej.wojcik has this become /ui/ ? I don't see a logs/server-info.html file. |
|
As for port configuration it can be changes as stated at [[Configuration]] wiki page /ui/ is for Sure.IM website project being deployed at local Tigase XMPP Server to be able to manage Tigase XMPP Server using web console. As for @logs/server-info.html@, I added this dummy (almost empty) file a long time ago to Tigase XMPP Server project or to Tigase HTTP API project and it should be replaced by running Tigase XMPP Server with some informations. I think it should be generated by Monitor component which is not yet finished - I think %bmalkow was working on this component. So this are two different things. |
Type |
New Feature
|
Priority |
Normal
|
Assignee | |
RedmineID |
2103
|
Add a simple HTTP API handler which will present user with current state of his installation, presenting some basic information and reporting possible problems if any is discovered.