Skip to content
This repository has been archived by the owner on Apr 20, 2023. It is now read-only.

Correct way to access log files (or using the invokeGet function) #22

Open
Taronyuu opened this issue Jan 6, 2017 · 6 comments
Open

Comments

@Taronyuu
Copy link

Taronyuu commented Jan 6, 2017

Hi everyone,

I have been trying to access the log files of a domain for a while now, but since there is no existing function for it I'm using the invokeGet function. However it looks like either the request isn't being executed correctly or I'm using the wrong function.

A bit of code, I tried the SHOW_LOG command taken from the URL but also the LOG_VIEWER taken from the DA website. (https://www.directadmin.com/features.php?id=1360) Both return the same result.

DirectAdmin::connectReseller(env('PANEL_HOST'), env('PANEL_USER'), env('PANEL_PASSWORD'))
            ->impersonateUser($userName)
            ->invokeGet('SHOW_LOG', [
                'domain'    => $domainName,
                'type'      => 'log',
            ]);
DirectAdmin API returned text/html to GET /CMD_API_SHOW_LOG containing
You cannot execute that command
The request you've made cannot be executed because it does not exist in your authority level

I'm not sure if I this is related to the DirectAdmin API or this package, but I'm hoping someone can help me. :)

@Taronyuu
Copy link
Author

Taronyuu commented Jan 8, 2017

As far as I know neither the CMD_API_SHOW_LOG or the CMD_API_LOG_VIEWER commands do exist so instead I decided to use the regular CMD_SHOW_LOG command.

Too bad this package (understandably) forces the use of CMD_API_ so I had to fork the package and add my own custom functions. If you are interested I can open a pull request, in that case I should give the custom functions a better name.

While typing this I realized the logs are the only place where this is going to work, it might be a smarter idea to just add 2 custom functions to only show the log files instead of allowing all commands.

@curry684
Copy link
Member

curry684 commented Jan 11, 2017

Actually it shouldn't be that hard to tunnel 'regular' requests through there, but in all honesty this was indeed never an intended use case. In practice it would be trivial to open up the underlying connectivity functions - if we make BaseContext::getConnection public instead of protected, and expose the functions at https://github.com/omines/directadmin/blob/master/src/DirectAdmin/DirectAdmin.php#L127 you could trivially bypass the CMD_API prefix and API-specific handling there.

The reason I never did that in the first place is that exposing the connection part of the API, which is really well hidden right now, implicitly makes it something that has to be consistently maintained. While in all honesty the DirectAdmin API is not only a huge fricking mess right now that cost me a ton of headaches to wrap reliably (see these 2 functions...), but DirectAdmin is also currently undergoing major changes to its internal workings, which I heavily suspect includes cleaning up the mess they call an API right now.

So yeah, kinda torn on how to approach this hehe. Open to suggestions, including pull requests, but expect discussion as I do intend to keep the core project as clean and architecturally sane as possible.

@Taronyuu
Copy link
Author

I don't think exposing the getConnection() function is required, because as I already said the log command is the only place where this would work. Because that page doesn't include any html or css.

which I heavily suspect includes cleaning up the mess they call an API right now.

I don't think they even touched the API, they are only talking about a new skin.

So yeah, kinda torn on how to approach this hehe. Open to suggestions, including pull requests,
but expect discussion as I do intend to keep the core project as clean and architecturally sane as possible.

I understand, thats the reason why I requested some feedback. 😄 I'm not statistied with my current solution, I think adding a getLog($type = 'access') (or 2 seperate getAccessLog() and getErrorLog()) is currently the way to go. It is the easiest and cleanest solution while allowing people to access the logs.

curry684 added a commit that referenced this issue Jan 15, 2017
Separate API invocations more clearly from possible other invocations. Refs #22
@curry684
Copy link
Member

I just pushed a refactoring change in preparation of better support for this feature.

@curry684
Copy link
Member

On another note: given that https://www.directadmin.com/features.php?id=1360 is listed as "unfinished" and upcoming for 1.502 (current is 1.501) - should we even bother right now with this?

@curry684
Copy link
Member

Funny - it's currently at "unfinished" still for 1.514....

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants