Having issues with my 4Q that refuses to connect to the Q-software, without having to reboot the computer.....

If I click back and forth to the dashboard-page a few times a Q5 is listed as "disconnected" (I've never owned a Q5 in my life though.

This is really frustrating. Do you have a fix planned for this?
Unplugging\replugging the USB-cables doesn't make any difference. The only thing that SOMETIMES helps is rebooting the entire computer.
It will then work until the next time the computer goes into hibernation\sleep, and you'll have to repeat the process again.

From URL: https://www.daskeyboard.io/get-started/firmware.md

After updating the X50Q to v57.0.0 in Windows, when plugging it back into Linux, none of the LEDs except numlock light up.

Attempting to switch to color profiles using NUM 1-6 don't work at all. Fn+12 works for NKRO but that's about it.

Without the software available as well, it's basically impossible to get any form of lights to show up.

The local instructions here seem to use https, I didn't have any success using https, should the instructions say http instead?

Section:
https://github.com/DasKeyboard/q/blob/master/q-api-doc.md#creating-a-signal-cloud-and-local

I noticed that it's possible to authenticate against the OAuth token endpoint via HTTP. According to the OAuth RFC, authorization servers MUST require the use of TLS.

Since requests to the token endpoint result in the transmission of
clear-text credentials (in the HTTP request and response), the
authorization server MUST require the use of TLS as described in
Section 1.6 when sending requests to the token endpoint.

When the device locks up, no keys work and usually there are a few keys still backlit, but most are dark.

Running latest firmware which stated that it fixed intermittent reboots. I had those reboots prior to the firmware, but I still get the USB disconnect/reconnect sounds from time to time.

I attempted to use USBLogView to see what is causing the issue but it doesn't log the disconnects consistently.

Also, the built in logs (quio.log and quio1.log) are both over a month old.

Every time I launch the software it immediately crashes.
I have tried reinstalling and I cannot find any logs in the install directories.

From URL: https://www.daskeyboard.io/updates/changelog-firmware.md

Where is the changelog for the X50Q?

When I link an application like Photoshop to a profile and I open Photoshop, it doesn't do anything. I have Das Keyboard X50Q and firmware at version - 64.0.0.

Since there are quite a few incompatibilities between the OAuth 2.0 spec and the Q API, I've decided to list them in one issue rather than create one for each. Some of these are major and some are minor, but in order to be OAuth compliant, they all need to be addressed.

Requirements

• Servers MUST support HTTP Basic authentication for client_id and client_secret. However, this is not required (nor supported) for the username and password parameters used with the password grant type. See 2.3.1 and #2.
• Authorization endpoints MUST require a response_type parameter with a value of code or token. See 3.3.1.
• Servers MUST support application/x-www-form-urlencoded POST bodies for some of its endpoints. See 4.1.3, 4.3.2, 4.4.2, 6, and #2.
• Servers MUST require a redirect_uri parameter when accepting requests with the authorization_code grant type. The value of the redirect_uri parameter MUST match the one used in the authorization request. See 4.1.3.
• The password grant type requires a username parameter. This API uses email instead. See 4.3.2.
• Servers MUST include a token_type parameter when granting a token. See 5.1.
• Servers MUST respond with an error parameter when it cannot, or refuses to, issue an access token. See 5.2.

I created a test suite to track these requirements. The status of tests can be viewed on Travis CI. The tests are ran daily.

Recommendations

• Clients SHOULD be required to use redirect endpoints secured with TLS (i.e. HTTPS). Loopback URLs are exempt from this as stated in RFC 8252. See 3.1.2.1.
• Clients SHOULD be required to register their redirect endpoints before using them. This prevents attackers from exploiting open redirectors. See 3.1.2.2.

The desktop app listens on 0.0.0.0, which means it listens on all IP addresses. This is a security issue because anyone on the same network can read and write your signals without authenticating (unless you have a firewall properly configured). These signals may contain sensitive information.

An option should be provided to choose the listen IP address. One of those options should be 127.0.0.1 (localhost). When using 127.0.0.1, only apps running on your computer will have access to the local API. It is also recommended to make 127.0.0.1 the default setting.

I originally posted this on the forum.

From URL: https://www.daskeyboard.io/get-started/software/

Download can't be installed on the latest macOS, Catalina. I've been trying to get this new Kickstarter keyboard to work, off and on, since I finally received it...

Client credentials (client_id and client_secret) can be used to obtain an access token, but beyond that, they aren't used for authentication. The purpose of OAuth client credentials is to authenticate third party services like IFTTT and Zapier, not to authenticate end users.

According to the OAuth RFC, client credentials are used for:

• Enforcing the binding of refresh tokens and authorization codes to
  the client they were issued to. Client authentication is critical
  when an authorization code is transmitted to the redirection
  endpoint over an insecure channel or when the redirection URI has
  not been registered in full.
• Recovering from a compromised client by disabling the client or
  changing its credentials, thus preventing an attacker from abusing
  stolen refresh tokens. Changing a single set of client
  credentials is significantly faster than revoking an entire set of
  refresh tokens.
• Implementing authentication management best practices, which
  require periodic credential rotation. Rotation of an entire set
  of refresh tokens can be challenging, while rotation of a single
  set of client credentials is significantly easier.

Note that this only applies to confidential clients like web applications that communicate with the Q API on the server backend over secure channels (i.e. not in a user's browser). They must be required to register their redirect URIs, and they should be required to use HTTPS. I'm not sure if you require IFTTT and Zapier to do that at this point.

Public clients, like mobile apps, desktop apps, or browser apps, that communicate to the Q API directly (not through a proxy web application as described earlier) should not be required to authenticate, nor should they even be given a client_secret, since they cannot securely store it. Also, they should only be allowed to use loopback redirect URIs.

End users have no need for client credentials, and giving a set to them by default can lead to confusion on how to use the API, especially when the client credentials are tied to their personal account rather than an app they are developing. End users can just use their username and password to authenticate against the API rather than having two sets of credentials that do the same thing.

On second thought, the password grant type should probably be disabled, but that's best described in another issue.

In conclusion, if you're not going to authenticate client credentials, then there's no need to have client_secrets at all.

Windows 10 x64
beta 2.0.0-7 software
DasKeyboard 5Q

The Q desktop app never loads, just a blank screen. Keyboard colors are no longer working on the keyboard (probably because the service/app are hung).

Upon rebooting the computer, colors will work during shutdown, but when computer comes back online they go dark again. seems like maybe something in the app is hung and doesn't fix until it is killed on shutdown

das-keyboard-q says disconnected forever until I restart the pc. Than it works till the next time the computer goes to sleep/hibernate.

I have a 4Q with the latest firmware and q software.

From URL: https://www.daskeyboard.io/get-started/software.md it will not allow update because Apple cannot verify for malware.

I have not found a user friendly way to revoke access from a client application, like IFTTT or Zapier. The only way I have found is through the API.

Are there plans to implement a web page to allow users to revoke client access?

From URL: https://www.daskeyboard.io/get-started/download.md

Zipped file for firmware complains that it cannot be opened on my mac because it is a windows file, despite the website suggesting that the firmware update is for All OS.

I just got my x50q and the q software is not effecting the keyboard at all. I have tried general rgb schemes as well as intalling applets and nothing changes the physical keyboard despite the dashboard representation changing as expected. What is going on?

From URL: https://www.daskeyboard.io/get-started/firmware.md

Cannot get X50 to connect to DaskeyboardQ software.

Are there any plans for X50Q to be supported for mac and linux? I know this is probably not the appropriate forum but if you don't plan to support it then what will I be missing out on if I'm not using the firmware. And is the support going to be a driver issue? If I run Q app in WINE, what's expected there?

EDIT: So let me ask this appropriately. I understand that Das has no plans to support, so just disregard everything I said. My question is now this: would it be possible for me to create support for X50Q or do you guys use proprietary blobs for interface?

From URL: https://www.daskeyboard.io/get-started/software.md

Q software on Mac OS Catalina just becomes unresponsive at the beginning of the install. I can't proceed. Kill it and tried multiple times. Just becomes unresponsive immediately.

That's not really funny, I'm working with an Hackintosh and using my X50q with Windows 10 and macos mojave.
Why there isn't a support for using the RGB Software and the Dashlets within Macos??

Is it only for the 5q? I'm not ready to pay more for something that could work that way !!!

Please make the software also working for macos!!!!!

RFC 6749, which defines the OAuth2 framework, states OAuth endpoints must accept application/x-www-form-urlencoded and may return application/json. Currently, the endpoint only accepts application/json, which makes it non-compliant with the RFC and a lot of standard library clients across varying languages.

Currently the Q Cloud authentication API doesn't work in Go with RFC-compliant, standard library client due to the incorrect mime type being accepted:

func NewClient(cid, cis string) *FiveQClient {
        // golang.org/x/oauth2/clientcredentials
	tconf := clientcredentials.Config{ 
		ClientID:     cid,
		ClientSecret: cis,
		TokenURL:     TokenPath,
	}

	c := tconf.Client(context.Background())
	return &FiveQClient{c, &Me{}}
}

// GetAuthorizedClients returns a list of AuthorizedClients which have been allowed access to the 5Q software.
func (f *FiveQClient) GetAuthorizedClients() ([]AuthorizedClients, error) {
	var ldevs []AuthorizedClients
	resp, err := f.Get(AuthorisedClients)
	if err != nil {
		return []AuthorizedClients{}, err
	}
	defer resp.Body.Close()

	decoder := json.NewDecoder(resp.Body)
	err = decoder.Decode(&ldevs)
	if err != nil {
		return []AuthorizedClients{}, nil
	}

	return ldevs, nil
}

Returns this error:

oauth2: cannot fetch token: 400 
		Response: {"code":"BAD_REQUEST","message":"Missing parameter (client_id)."}

Changing the server mime type from application/json to application/x-www-form-urlencoded should resolve the problem.

Currently the only client applications available are IFTTT and Zapier. Are there plans to allow developers to register their own client applications?

It's possible to create an account and use the Client ID at https://q.daskeyboard.com/account, but this just shows up as something like User_492 in the list of authorized clients when accessing the API.

It would be great if we could register client applications with descriptive names like Qwertydash™ The dashboard for your keyboard. These clients would get their own Client IDs that would be separate from user Client IDs. (In fact, user's don't even need Client IDs and Secrets, so I don't know why we have them in the first place.)

On a side note, it would also be better to revoke clients by ID rather than by name so that longer descriptive names can be used.

From URL: https://daskeyboard.github.io/get-started/download.md

Everytime I go to click to download the Q desktop, i get this message. I think one of your S3 Pointers is off.

From URL: https://daskeyboard.github.io/get-started/download.md

When trying to download I get this error:

"NoSuchKeyThe specified key does not exist.Das-Keyboard-Q-Setup-1.0.0-beta.43.exe2EEC2E15664058DEh87pyuxjIni6ev08pnlR655ojGoI2LBHdNJnAx2wGT5civMyWxiMfAempqgQiGnxf1YDR+RLYJM="

To all of you having issues getting your x50q detected and working with q software. There is a VERY hiddent firemware update that fixes the issues. Here is the link... https://www.daskeyboard.io/get-started/firmware/

This needs to be pushed by the q software in my opinion. Most people are not going to figure this out.

Hello! Is there a contact address for reporting security issues? I saw that previous concerns were just opened as issues on GitHub, is that the intended venue for reporting?

I also posted this question on the forum, but figure there may be a better chance of reaching a security contact here!

Also, love the keyboards! I have two :)

Can you please add a list of all signal areas available?

From URL: https://www.daskeyboard.io/get-started/software.md

I Need a RPM

Can the Q API include a way to update keyboard colors? I'm on a mac and I can't update the keyboard colors with the desktop app, I've got the default rainbow color scheme going. It would be nice to be able to do that over the API.

Thanks,

James

From URL: https://daskeyboard.github.io/get-started/download.md

Download link for Q Desktop is dead, doesn't point to a public or available resource.

From URL: https://www.daskeyboard.io/script-examples/cpu-percentage.md

The shell script seems to be missing. The page just displays the node script with extra whitespace.

These instructions seem to be for linux?

https://github.com/DasKeyboard/q/blob/master/q-api-doc.md#step-by-step-das-keyboard-q-rest-api-documentation

The... software as far as I know only runs on Windows, so it would be nice to have windows instructions to find the port.

Also how is the port generated, it seemed to stay the same at 27301 even after a re-install?

From URL: https://www.daskeyboard.io/get-started/software.md

I am getting the following errors after downloading the installation .pkg. Please see the screenshot below:

I've create a Zap in Zapier, where for a mention is slack, the S would 'BREATH` in magenta color.

What really happens when I test it (using Zapier's testing option) is that the right SUPER key is being lit, indeed in magenta and does have the breath effect but on the wrong key. Changing the key, changing the type of Zap or changing from 4Q to 5Q (even though I have the 4Q) does not help.

Firmware is upgraded to the latest available.

This scenario happens on Ubuntu 18.04

From URL: https://www.daskeyboard.io/applet-development/index.md

Missing documentation of qConfig into package.json
There is not a complete set of the available controlType that we can use inside the questions array. For example is there any colorpicker component?

Running the installer for version 2.0.3 "fails" with this message:

CreateProcess failed; code 2.
The system cannot find the file specified.

The file in question is Service Module.exe. After the installer closes, the "q" splash screen shows up for a couple seconds then crashes with no message. At this point there is no Das Keyboard service running, and manually running the service from the install directory doesn't change DasKeyboardQInstaller.exe's behavior (splash screen then crash).

No logs are generated in \AppData\Roaming\das-keyboard-q\logs.

Just received my 5Q keyboard and it feels quite nice. The only disappointment is the key the backslash & pipe key does not illuminate. The "Das Keyboard Q" application recognises this as an American keyboard and although when hitting the keys, the correct characters are sent, it's not the case when managing key illumination through the application.

The \ & | key (second row from bottom, second key from left) is permanently un-lit and there are no options to illuminate it, or certainly non that I can find on the application.

UK layout with latest firmware 7.4.18.

I've tried setting the key colour through the shell script example and all that happened was the keys on the grid, 2,4 and 2,3 illuminated together, but my keyboard has independent 2,3 and 2,4 instead of the longer shift key.

Was so looking forward to getting this keyboard and I'm a bit miffed. Any idea on a time fix?

Thanks,
D

After reboot I am able to connect to keyboard, change its settings and add some applets, but during working day it just stops service and disconnects, so applets freeze on last state.

From URL: https://www.daskeyboard.io/api-ressources/signal/get-signals.md

There is no documentation for using the localhost API. The page says Q Cloud Only but below that has a deprecation notice saying to use the localhost API or Q Applet API.

I have tried calling /api/1.0/signals and /signals and both resources return the following message:

Cannot GET /api/1.0/signals

Is there any chance this software will ever be open source? Currently, there's a LOT of features the API is missing, batching signals, custom LED events, some way to trigger responses to events, all kinds of stuff. I'm sure you guys are working on it, but just as I'm writing open source clients to use the API, open source contributions to the underlying systems would be nice to see as well.

From URL: https://www.daskeyboard.io/applet-development/user-questions.md

Hi, I noticed that a color picker control type is missing. It would be a great improvement if you exposed a color picker component.

From URL: https://www.daskeyboard.io/q-authentication.md

Refreshing the Oauth token
curl -X POST -H "Content-Type: application/json" -d '{"client_id": "CLIENT_ID", "grant_type": "refresh_token", "refreshToken": "REFRESH_TOKEN"}' https://q.daskeyboard.com/oauth/1.4/token

Should be
curl -X POST -H "Content-Type: application/json" -d '{"client_id": "CLIENT_ID", "grant_type": "refresh_token", "refresh_token": "REFRESH_TOKEN"}' https://q.daskeyboard.com/oauth/1.4/token

Hey I have a problem with running the Software on archlinux. Since It is only available as a .deb file, I had to manually convert/install it. Finally, I got it running but unfortunately it doesn't recognize my device. I also tested the keyboard on my Ubuntu laptop, where it worked fine to prevent hardware or firmware issues. Are there other Archlinux users out there to help me?

As the title says, the software displays two keyboard types, both "unplugged". I'm typing this with the plugged in 5Q.

This is the case on two machines:

Windows 7 Pro, 64 bit, SP1
Q Software v1.0.0-beta.43
Latest Firmware at time of writing (firmware software detects keyboard firmware fine)

Log attached
quio.log

I've attempted to update my firmware to the newest several times. However, each time the keyboard flickers and cycles RGB patterns before ultimately telling me the firmware upgrade has failed.

The password grant type should be disabled. Enabling it just encourages the development of insecure clients that are doing who-knows-what with your login info. Clients should be required to use the authorization_code grant type. The only location users should be entering their username and password is on the q.daskeyboard.com domain. Best practices are outlined in RFC 8252.