Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 7 of 7 total
Thread LogOutput: What do I miss?
Sun, Apr 29 2018 6:51 AMPermanent Link

Ralf Mimoun

Hi all,

I started to use EWB seriously some days ago, after playing around with it since version 1 (beta?). Now I don't understand why I waited for so long Smile

As we all know, logging ist important. So I was very pleased to find the LogOutput command. Per default, it should log to the "log" URL.

That does work - sort of. DEFAULT_LOG_URL is "http://localhost/log", which does not help when the web server runs on a different port, say 88. And even with "log" as LogURL parameter for LogOutput, you get a "Resource /log not found" error when you try to open http://localhost:88/log. So, logging is only fully available if you run the internal web server on Port 80. Or do I miss something?

Ralf
Sun, Apr 29 2018 12:12 PMPermanent Link

Raul

Globestar Systems

Team Elevate Team Elevate

On 4/29/2018 6:51 AM, Ralf Mimoun wrote:
> As we all know, logging ist important. So I was very pleased to find the LogOutput command. Per default, it should log to the "log" URL.
>
> That does work - sort of. DEFAULT_LOG_URL is "http://localhost/log", which does not help when the web server runs on a different port, say 88. And even with "log" as LogURL parameter for LogOutput, you get a "Resource /log not found" error when you try to open http://localhost:88/log. So, logging is only fully available if you run the internal web server on Port 80. Or do I miss something?

Default URL is a small limitation.

I think it should default to simply "/log" (instead of
http://localhost/log) and that should handle the different internal web
server  auto magically since it's relative URL.

LogOutput does allow one to supply your own url in the 2nd parameter
though. If you called it as

LogOutput('my sample log entry','/log')"

it should show up even if you're on 88 or any other port with IDE web
server.

Logging in general of course is a bigger topic since you would need
back-end web server to actually be able to handle this logging (i.e.
"/log" or similar url) and maybe store it and a way to show it etc.

I'm using a small global logging class that i can call anywhere in the
app and that stores the log strings and can then show them in a form
with memo if needed (in app) or optionally also send it to any custom
URL (using the LogOutput with 2nd param).

Raul

Mon, Apr 30 2018 7:37 PMPermanent Link

Ralf Mimoun

Thanks, that's what I suspected. Using a /log url can be a security problem, so you have to add some kind of access control. I am very curious to see the enhancements in that area in EWB 3.
Mon, Apr 30 2018 11:13 PMPermanent Link

Raul

Globestar Systems

Team Elevate Team Elevate

> Thanks, that's what I suspected. Using a /log url can be a security problem, so you have to add some kind of access control. I am very curious to see the enhancements in that area in EWB 3.
>

Can you elaborate what the security problem is that you're thinking about ?

I cannot think of anything new when using current implementation and
'/log' ?! (other there being single logging endpoint for any apps).

Raul
Tue, May 1 2018 8:44 AMPermanent Link

Ralf Mimoun

Raul,

sometimes you add infos to a log that should not be there, like user names or even passwords. It can be less obvious, like logging raw data used for a calculation that some users should not see. You don't want to show every customer your stock or prime costs. But from time to time, you throw them in the log because of an epic bug hunt you try to survive. Hey, better log more than less. And more often than less, you leave the log calls, as long as they don't hurt the performance. If there is one bug, then there are many more, sometimes nastier than the one you just smashed. Ok. too much Starship Troppers.

And then someone tries the /log URL. Yes, that problem exist right now.

Ralf


Raul wrote:

> Thanks, that's what I suspected. Using a /log url can be a security problem, so you have to add some kind of access control. I am very curious to see the enhancements in that area in EWB 3.
>

Can you elaborate what the security problem is that you're thinking about ?

I cannot think of anything new when using current implementation and
'/log' ?! (other there being single logging endpoint for any apps).

Raul
Tue, May 1 2018 8:52 AMPermanent Link

Matthew Jones

Ralf Mimoun wrote:

>  that some users should not see.

I presume that the /log facility is about POSTing log info TO the server, and never showing it back again. That eliminates all the issues you suggest as the user has all the data in their browser already, so you are not revealing anything new by logging.

The only issue I can see is if someone DoS attacks by sending a few terabytes of log...

--

Matthew Jones
Tue, May 1 2018 9:37 AMPermanent Link

Ralf Mimoun

You are right. I don't know why I thought that you could see the log entries by visiting http://<address>/log.


"Matthew Jones" wrote:

Ralf Mimoun wrote:

>  that some users should not see.

I presume that the /log facility is about POSTing log info TO the server, and never showing it back again. That eliminates all the issues you suggest as the user has all the data in their browser already, so you are not revealing anything new by logging.

The only issue I can see is if someone DoS attacks by sending a few terabytes of log...

--

Matthew Jones
Image