wakapi icon indicating copy to clipboard operation
wakapi copied to clipboard

Support wakatime-chrome extension

Open shyn opened this issue 2 years ago â€Ē 19 comments

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.

shyn avatar Aug 30 '21 01:08 shyn

Screenshot_2021-08-30_13-39-33 I think you're right. It doesn't seem to be adjustable.

YC avatar Aug 30 '21 03:08 YC

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?

muety avatar Aug 30 '21 06:08 muety

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!

shyn avatar Aug 30 '21 09:08 shyn

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.

gaocegege avatar Oct 10 '21 07:10 gaocegege

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.

gaocegege avatar Oct 10 '21 08:10 gaocegege

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

gaocegege avatar Oct 10 '21 08:10 gaocegege

Thanks for investigating! I'll have a look at the user agent issue soon.

muety avatar Oct 10 '21 08:10 muety

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.

gaocegege avatar Oct 10 '21 09:10 gaocegege

I have a good solution in mind and will implement it soon. Stay tuned!

muety avatar Oct 10 '21 13:10 muety

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.

muety avatar Oct 13 '21 14:10 muety

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 avatar Oct 14 '21 02:10 gaocegege

@gaocegege Are you still on this?

muety avatar Oct 23 '21 12:10 muety

Yeah but do not have much bandwidth for it. :worried:

gaocegege avatar Oct 23 '21 12:10 gaocegege

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.

muety avatar Oct 30 '21 18:10 muety

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?ðŸĪŠðŸĪŠ

f97-2308 avatar Mar 21 '22 01:03 f97-2308

I am developing a small extension, I hope I will release it soon.

image

f97-2308 avatar Mar 23 '22 01:03 f97-2308

@f97 How is going forward with your extension? Is there anything we can help you with?

muety avatar Apr 09 '22 11:04 muety

@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

image

f97-2308 avatar Jul 13 '22 01:07 f97-2308

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.

muety avatar Jul 14 '22 13:07 muety

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:

alexanderadam avatar Dec 28 '22 19:12 alexanderadam

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! 🙂

muety avatar Dec 29 '22 09:12 muety

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:

muety avatar Mar 11 '23 14:03 muety

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 :-)

qhantom avatar Mar 11 '23 14:03 qhantom

@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:

image

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.

varac avatar Mar 12 '23 22:03 varac

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!

muety avatar Mar 13 '23 05:03 muety

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.

muety avatar Mar 16 '23 20:03 muety

Great! As soon as there's a new image tag I'll test and can give feedback. Thanks!

varac avatar Mar 16 '23 20:03 varac

browser-wakatime now supports sending data to Wakapi. See instructions here. :heavy_check_mark:

muety avatar Jul 30 '23 06:07 muety