Skip to content

JetBrains: Make auth more convenient

Warren Gifford requested to merge dv/jetbrains-make-auth-more-convenient into main

Created by: vdavid

Closes https://github.com/sourcegraph/sourcegraph/issues/36783

The work items here were these:

  1. Add "User authentication" and "Navigation settings" groups
  2. Add help texts
  3. Set up URL syntax validation
  4. Set up automatic access token validation after an access token change or URL change

Details on each:

1. Grouping: It was a pain. It was rather difficult to figure it out without the UI Inspector, which I couldn't make work at first. But then today morning I managed to pop it up: I still don't have a menu item for it, but ⌃⌥click brings it up in my sandboxed instance! So that made it somewhat quicker, and I've added the two groups and the indentation to make the two groups of settings look somewhat like JetBrains' UI guidelines.

2. Help texts: I've added many of them. They don't closely follow the figma but we discussed with @jjinnii that even the figma versions are not final and let's not get blocked by the final copy, as it's something that's relatively easy to change later.

3. URL validation: Turns out that JetBrains has pretty good guidelines for this, that even includes some code! The code is somewhat obsolete and it didn't really work for me out of the box, but I found a way and now it's very stable. I also extracted the most verbose parts to private methods, so now we can add validations with lambda functions in a much more concise way. The validation itself is not my custom one but one that's part of JsonSchemaConfigurable, as this seemed to be the most standard one. TBH, it's cr*p, it basically notices if a URL doesn't start with "http", but accepts pretty much everything else. I think this is a good baseline of defense, though.

4. Token validation: I only implemented a simplistic version. I think this is acceptable, but I'm also interested in other opinions. Currently, the validation only considers the field valid if it's either exactly 40 characters long, or empty. This should cover most honest mistakes. The next step here would be to implement remote validation, but:

  • Currently, we only have the access token validation code on the JS side, and adding it to the Java side would result in some duplication of functionality, and would take time.
  • I already took so long with this because of the lack of documentation on Swing and IntelliJ components that I'd prefer to cut this effort short and go with this more simplistic validation. I honestly think it helps users with the most common mistakes like not copying the first/last character of the token.

Test plan

App preview:

Check out the client app preview documentation to learn more.

Merge request reports

Loading