You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(Disclaimer: I'm actually Portuguese, but for the sake of non-Portuguese speakers, I'll post this in English instead).
For years and years, I have been trying to get good old rclone to connect to MEO Cloud using the Dropbox API, which should work; my problem was only to make sure I get a valid reply from MEO's servers! And this, in turn, pushed me to take a look at how others have dealt with the issue.
Firstly, I installed your application on a Linux x64 server running Ubuntu 22.04. Compiling with gcc 11.4.0 provided a clean, working executable. meocloud-upload --init recognised my authentication details without a glitch (after I switched the authentication type to OOB), I inserted the PIN, and it accepted it, saving the configuration as expected. Then I uploaded a file; no surprises there, it worked fine.
Secondly, I tried to do the same under macOS 11.7.9 (also x64). The default compiler I've got installed (via homebrew) is clang 17.0.6, mostly because Apple's version is stuck with 13.0.0 (way too old). Apple's gcc is actually symlinked by Apple to clang; I have gcc 13.2.0 but it's a pain to get it set up... therefore, I just used clang.
clang, under macOS, compiles fine (interestingly, the warnings are slightly different, but the compilation succeeds). The executable works, and, like the Linux version, it accepts my authentication details, calls MEO's auth server, displays the URL for getting the authentication, which, in turn, will correctly generate the appropriate PIN... copy-paste it into the CLI, get the refresh token and so forth... and then it gives an error. And stops the configuration.
Oh, and no ~/.meocloud.conf is ever written (or overwritten).
I experimented many different things, including creating a fresh, new ~/.meocloud.conf manually, see if it helped, and forcing meocloud-update to read from it. It clearly ignored the file, therefore requesting an initialisation. Once again, though, the process completed successfully, returning what I presume to be a valid token, but then it mysteriously fails with the [Erro] message.
By looking at the code, it seems that the reason for the failure to write ~/.meocloud.conf is easily explained:
#ifdefOS_UNIX//... do some magic with file descriptors
Okay, that tag is not familiar to me, and what might be happening is that Homebrew's clang doesn't define it explicitly.
And, indeed, this is a locally-defined tag, along with a few others, which are explicitly set under Utils.h, around lines 6-9:
Utils.h (lines 6-9)
#ifdef__unix__#defineOS_UNIX
While it seems that GCC does, indeed, define __unix__ under Linux, there is no guarantee whatsoever that it's being defined under other Unix or Unix-like systems. In fact, the recommended line to check for most Unix/Unix-like flavours is rather long, e.g.
This should handle pretty much everything out there (allegedly, even Darwin, upon which macOS is based, will also define __APPLE__ & __MACH__).
Once I've made this simple change, everything compiled flawlessly and produced identical results to the Linux version 😄
But that line is rather long, and perhaps it's worth considering the alternative — i.e., define OS_UNIX as being not Windows, since the number of 'official' tags for Windows are very few (_WIN32 being the most common one).
Of course, there might be exceptions out there — for instance, what does iOS or Android return? Both, of course, are Unix-flavoured (iOS is Darwin, Android is Linux), but they might lack a lot of library functions (I haven't got the slightest idea).
Anyway, in any case, to actually get this to compile under macOS, that's the only change you need to do :)
Thanks for all your work on this tool. After experimenting a bit, I've got some clues about why it doesn't work so well with rclone, but the fix is non-trivial (I got as far as getting an "Invalid request" from MEO's web page — better than "authentication failed" which was how far I managed to previously go).
Some other suggestions for you:
It would probably be nice if, instead of just showing [Erro], you could be a bit more descriptive in what kind of error was thrown. It would have helped someone unfamiliar with your code to track it down! Even showing the line/file where the error was thrown would be quite helpful.
When saving the meocloud.conf file, consider compliance with the XDG Base Directory Specification, which has become increasingly popular to try to handle the (current) mess of everything written under the home directory. Rather — and in the case of your tool — this would mean storing the file as ~/.config/meocloud-upload/meocloud.conf instead. There are very good reasons for this approach, all thoroughly explained in that document 😄
And for the sake of completeness, here go the logs of what I got before changing how OS_UNIX is defined (note how well your code works through a web proxy!):
Log from incorrectly-compiled macOS version
$ meocloud -c ~/.meocloud.conf -v --init
Consumer key: [REDACTED]
Consumer secret: [REDACTED]
Nivel de acesso: Meocloud/Sandbox? [M/s] M
Consumer key introduzida: '[REDACTED]'
Consumer secret introduzido: '[REDACTED]'
Nivel de acesso: Meocloud
Deseja continuar? [s/N] s
Insira o seguinte link no browser e autorize a aplicacao:
Hi,
(Disclaimer: I'm actually Portuguese, but for the sake of non-Portuguese speakers, I'll post this in English instead).
For years and years, I have been trying to get good old
rclone
to connect to MEO Cloud using the Dropbox API, which should work; my problem was only to make sure I get a valid reply from MEO's servers! And this, in turn, pushed me to take a look at how others have dealt with the issue.Firstly, I installed your application on a Linux x64 server running Ubuntu 22.04. Compiling with gcc 11.4.0 provided a clean, working executable.
meocloud-upload --init
recognised my authentication details without a glitch (after I switched the authentication type to OOB), I inserted the PIN, and it accepted it, saving the configuration as expected. Then I uploaded a file; no surprises there, it worked fine.Secondly, I tried to do the same under macOS 11.7.9 (also x64). The default compiler I've got installed (via homebrew) is clang 17.0.6, mostly because Apple's version is stuck with 13.0.0 (way too old). Apple's
gcc
is actually symlinked by Apple to clang; I have gcc 13.2.0 but it's a pain to get it set up... therefore, I just used clang.clang, under macOS, compiles fine (interestingly, the warnings are slightly different, but the compilation succeeds). The executable works, and, like the Linux version, it accepts my authentication details, calls MEO's auth server, displays the URL for getting the authentication, which, in turn, will correctly generate the appropriate PIN... copy-paste it into the CLI, get the refresh token and so forth... and then it gives an error. And stops the configuration.
Oh, and no
~/.meocloud.conf
is ever written (or overwritten).I experimented many different things, including creating a fresh, new
~/.meocloud.conf
manually, see if it helped, and forcingmeocloud-update
to read from it. It clearly ignored the file, therefore requesting an initialisation. Once again, though, the process completed successfully, returning what I presume to be a valid token, but then it mysteriously fails with the[Erro]
message.By looking at the code, it seems that the reason for the failure to write
~/.meocloud.conf
is easily explained:In file
Meocloud_API.cpp
, underAPI::WriteFile()
, line 403 shows:Okay, that tag is not familiar to me, and what might be happening is that Homebrew's
clang
doesn't define it explicitly.And, indeed, this is a locally-defined tag, along with a few others, which are explicitly set under
Utils.h
, around lines 6-9:Utils.h (lines 6-9)
While it seems that GCC does, indeed, define
__unix__
under Linux, there is no guarantee whatsoever that it's being defined under other Unix or Unix-like systems. In fact, the recommended line to check for most Unix/Unix-like flavours is rather long, e.g.This should handle pretty much everything out there (allegedly, even Darwin, upon which macOS is based, will also define
__APPLE__
&__MACH__
).Once I've made this simple change, everything compiled flawlessly and produced identical results to the Linux version 😄
But that line is rather long, and perhaps it's worth considering the alternative — i.e., define
OS_UNIX
as beingnot Windows
, since the number of 'official' tags for Windows are very few (_WIN32
being the most common one).Of course, there might be exceptions out there — for instance, what does iOS or Android return? Both, of course, are Unix-flavoured (iOS is Darwin, Android is Linux), but they might lack a lot of library functions (I haven't got the slightest idea).
Anyway, in any case, to actually get this to compile under macOS, that's the only change you need to do :)
Thanks for all your work on this tool. After experimenting a bit, I've got some clues about why it doesn't work so well with
rclone
, but the fix is non-trivial (I got as far as getting an "Invalid request" from MEO's web page — better than "authentication failed" which was how far I managed to previously go).Some other suggestions for you:
[Erro]
, you could be a bit more descriptive in what kind of error was thrown. It would have helped someone unfamiliar with your code to track it down! Even showing the line/file where the error was thrown would be quite helpful.meocloud.conf
file, consider compliance with the XDG Base Directory Specification, which has become increasingly popular to try to handle the (current) mess of everything written under the home directory. Rather — and in the case of your tool — this would mean storing the file as~/.config/meocloud-upload/meocloud.conf
instead. There are very good reasons for this approach, all thoroughly explained in that document 😄And for the sake of completeness, here go the logs of what I got before changing how
OS_UNIX
is defined (note how well your code works through a web proxy!):Log from incorrectly-compiled macOS version
< HTTP/1.1 200 Connection established
<
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Server: nginx
< Content-Type: application/json;charset=UTF-8
< Content-Length: 165
< Connection: keep-alive
< x-xss-protection: 1; mode=block
< Content-Language: pt
< Vary: Accept-Language, Cookie
< Pragma: no-cache
< Cache-Control: no-store
< Date: Fri, 19 Jan 2024 17:13:46 GMT
< X-Frame-Options: SAMEORIGIN
< Set-Cookie: sessionid=v03a36fy10295h9mubzq83df5kwgev45; Domain=.meocloud.pt; httponly; Path=/; secure
< Strict-Transport-Security: max-age=31536000
< Cache-Control: no-store
< Pragma: no-cache
<
-- Start Output --
{"access_token": "[REDACTED]", "token_type": "Bearer", "expires_in": 31536000, "refresh_token": "[REDACTED]", "scope": "ALL"}
--End Output--
Refresh Token: [REDACTED]
Access Token: [REDACTED]
Token recebido expira dentro de 31536000 segundos
[Erro]
$
The text was updated successfully, but these errors were encountered: