-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Make mapbox access token configurable via layout attribute #729
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
- use token in gd._context if not present in fullLayout - make sure map is removed + re-created if access token changes -
|
||
promise.catch(function(err) { | ||
expect(gd._fullLayout.mapbox.accesstoken).toEqual('wont-work'); | ||
expect(err).toEqual(new Error(constants.mapOnErrorMsg)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chriddyp Important Setting a wrong access token currently:
- throws an error,
- clears the map, and
- does not update
fullLayout.mapbox.accesstoken
Is this something you can work with the workspace? If not, please let me know. Alternatively, we could:
- as the above, but clear
fullLayout.mapbox.accesstoken
if it is invalid - eat up the error ...
- anything else?
Note also that setting an invalid mapbox.style
does essentially the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chriddyp @etpinard one thing we can do is to make our token validation impeccable (maybe validate our token against the real mapbox api endpoint). @BRONSOLO has opened an issue about it https://github.com/plotly/streambed/issues/7010. For now in my opinion when the user supplies a bad token/style
we catch the error then pop up an error dialogue telling them what is going on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lpan So, what are you proposing?
one thing we can do is to make our token validation impeccable
I'd vote 👎 for adding token validation in plotly.js. Making one request to validate the token and then one to plot the map sounds like an overkill. No?
For now in my opinion when the user supplies a bad token/style we catch the error then pop up an error dialogue telling them what is going on.
... as currently off this branch, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd vote 👎 for adding token validation in plotly.js. Making one request to validate the token and then one to plot the map sounds like an overkill. No?
No no no 😛 I meant when the user add a mapbox token in setting. our backend makes a request to the mapbox to validate the token. If it is not valid, they cant even add the token. So we are sure that all of the tokens in the the token dropdown are valid
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... as currently off this branch, correct?
yep
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lpan Thanks for the clarification!
💃 👍 |
@chriddyp
In brief
Users can now register their mapbox access token via
layout.mapbox.accesstoken
:This is especially important for users wanting to use a custom map style - where setting the access token in
layout
guarantee that the map will look the same regardless of the specifiedconfig
options.If
mapbox.accesstoken
isn't specify, the configmapboxAccessToken
is used.