wakapi
wakapi copied to clipboard
Support wakatime-chrome extension
Installed chrome extension from wakatime.com. It's seems like I can't set the api endpoint. So the only way is the clone the source code and replace wakatime api with wakapi?
Searched issues found nothing about this.
I think you're right. It doesn't seem to be adjustable.
Very unfortunate! I opened https://github.com/wakatime/chrome-wakatime/issues/130 in the upstream repo, let's see if some solution can be found. @shyn, are you using wakapi.dev or a self-hosted instance?
Very unfortunate! I opened wakatime/chrome-wakatime#130 in the upstream repo, let's see if some solution can be found. @shyn, are you using wakapi.dev or a self-hosted instance?
I use a self-hosted instance. Appreciate the upstream issue. I will watch it, thx!
It may not easy to implement. I have a deep dive into it. The chrome extension defines the host permission here
https://github.com/wakatime/chrome-wakatime/blob/master/manifest.json#L35
I updated the heartbeat URL to my own wakapi deployment and it issued CORS problem.
After I solved the problem with supporting OPTIONS in wakapi, the ajax post request from the chrome extension does not come with cookies because of this
Still trying to fix it now.
I ran the chrome extension successfully, but we cannot get the correct os/editor/machine because of the user-agent. The user-agent from the browser looks like Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36
wakapi cannot parse it.
I updated these parts in the chrome extension:
- https://github.com/wakatime/chrome-wakatime/blob/master/manifest.json#L34 Added my own hostname here.
- https://github.com/wakatime/chrome-wakatime/blob/master/assets/js/config.js#L21 Change the config to my own endpoints
Thanks for investigating! I'll have a look at the user agent issue soon.
Thanks! We can maintain a chrome-wakatime fork to support wakapi.dev. But it is hard to keep one extension for all self-hosted instances. We need to work around ajax/chrome extension CORS problems.
I have a good solution in mind and will implement it soon. Stay tuned!
Okay, so here's the plan:
- [x] Fork the official plugin
- [x] https://github.com/muety/chrome-wakapi/issues/1
- [ ] https://github.com/muety/chrome-wakapi/issues/2
- [ ] https://github.com/muety/chrome-wakapi/issues/3
- [ ] Publish
chrome-wakapi
plugin to Chrome- and Firefox stores - [ ] Add usage instructions to README
Right now, this is blocked by https://github.com/wakatime/chrome-wakatime/issues/135. Unfortunately, I can't properly build the plugin, so I can't continue with the above points. Maybe it's only me, but otherwise we'll have to wait for someone to fix the plugin build.
Also, help is highly appreciated here, especially because the plugin is written in React, which I don't have any expertise with.
I can help with it. I am a backend guy but used to hack on chrome wakatime plugin. Will see what I can do here.
@gaocegege Are you still on this?
Yeah but do not have much bandwidth for it. :worried:
Sorry, I don't want to pressure you. If you think you can't afford time for this more or less soon-ish then I'll have a look. However, it's probably gonna take me much longer, as I'm not familiar with React, etc.
I just found wakapi but I am very love it and I am intending to support this task but I found this extension uses manifest v2. I don't know if wakatime has any plans to move to v3 version?ðĪŠðĪŠ
I am developing a small extension, I hope I will release it soon.
@f97 How is going forward with your extension? Is there anything we can help you with?
@muety
hehe, I've had a lot of problems with my life, work, so I can't make time for the promise of writing this extension.
I have a bit of free time these days so I quickly code a small extension, but I'm having a problem that I don't know what to push.
I tried a few things but still not satisfied, you can contribute here.
At least it works but it doesn't work properly: 3
https://github.com/f97/chrome-wakapi.git
That is great news! I'm excited to check out what you already came up with. Maybe you can add a brief list of things that would still need to be done / are not working yet - e.g. in the form of issues or as part of your project's README - and I'm sure people will be happy to jump in and contribute to get this thing live! ð
And of course, don't feel obliged here by any means! Get your private stuff sorted and only spend time on coding this if you actually feel like so.
I like the relay idea although it would be easier with dynamic hosts of course but I guess that's not possible. Just to throw another idea into the room:
if the wakapi host would be provided (i.e. WAKAPI_API_URL
), then wakapi could build the extensions on Docker boot (maybe some npm build
resulting in an URL dependent file name, so that it won't be rebundled if the hostname or the file hashes didn't change) and put them into the asset directory.
Of course this would mean, that a new wakapi container image must be pulled to get the updated extension but on the other hand this would also make sure that the API always matches.
And I think there's an extra warning when installing extensions from other hosts.
But other than that it would be nice because users know that they don't have to send their activities via a third party.
I'm not sure whether any of what I wrote makes any sense, though. :wink:
I'll have a look into content scripts to see if that could help us by any means. Thanks for the pointer.
Apart from that, if I got your solution approach (building the extension with custom API URL at container build- / run time) correctly, it would mean that everyone, who is self-hosting Wakapi, would have to build and install their own browser extension, no? Of course, this is always an option. But I'd like to have a solution where people can just go to the Chrome / Firefox store and install an official add-on right from the marketplace.
However, the main blocker on this ticket is anyways the extension itself, which would require a few adaptions, but whose code unfortunately seems to be abandoned.
Again, if anyone has good expertise with (a) React and (b) the WebExt API, help is highly appreciated here! ð
https://github.com/wakatime/chrome-wakatime/issues/135 finally got resolved in the upstream repo, so no more blockers for us! :raised_hands:
Next steps: as described above.
I'd be super thankful if someone with a bit of React experience could help out in this! @qhantom, maybe? :innocent:
wakatime/chrome-wakatime#135 finally got resolved in the upstream repo, so no more blockers for us! ð
Next steps: as described above.
I'd be super thankful if someone with a bit of React experience could help out in this! @qhantom, maybe? ð
Sure, gonna have a look at https://github.com/muety/chrome-wakapi/issues/2 :-)
@muety I also got the official chrome-wakatime plugin compiled and successfully installed, after I changed the URL in the source to my wakapi server. In the inspector window I see requests beeing sent to my server on every new website I visit:
my Wakapi server recieves the requests:
2023-03-12T22:12:28.00305202Z [INFO ] [request] status=201, method=POST, uri=/api/v1/users/current/heartbeats?api_key=..., duration=42.284249ms, bytes=27, addr=x.x.x.x, user=varac
But I don't see anything in my dashboard (besides my NeoVim plugin entries). How can I debug further, or has Wakapi still issues with parsing the useragent payload entry as mentioned above (https://github.com/muety/wakapi/issues/237#issuecomment-939427621) ?
I also don't see any domains showing up in the Dashboard. Any help appreciated on how to get the chrome-wakatime plugin working before any of the plugins support custom URLs from UI.
Hi @varac, thanks for reporting this!
To clarify, you don't see your coding time reflected in the Wakapi dashboard at all or is it just classified as unknown? Also, do you see any error messages in the server's logs?
The user agent issue from above most likely still persists. I'll look into it soon!
I fixed parsing the user agent strings, so you should see "Chrome" appearing as an editor now.
However, I realized that domains / web pages are implemented as entities (aka. files), while Wakapi currently does not support file statistics at the moment. I'll have to reconsider this, because otherwise, the browser plugin would be rather useless.
Great! As soon as there's a new image tag I'll test and can give feedback. Thanks!
browser-wakatime now supports sending data to Wakapi. See instructions here. :heavy_check_mark: