* Adds note about use of Fastly VCL for redirects
Some redirects are not possible with a redirect file, so we send traffic to
learn.hashicorp.com with custom VCL (Varnish) handlers using the Fastly web
admin.
Future migrations of content to learn.hashicorp.com should also use this
approach.
* adding file2consul listing
* minor edit
* modified wording added some punctuation
* Moved file2consul so it is listed in alpha order. Replaces Pull Request # #4942
Fix catalog service node filtering (ex /v1/catalog/service/srv?tag=tag1)
between agent version <=v1.2.3 and server >=v1.3.0.
New server version did not account for the old field when filtering
hence request made from old agent were not tag-filtered.
* website: add multi-dc enterprise landing page
* website: switch all 1.4.0 alerts/RC warnings
* website: connect product wording
Co-Authored-By: pearkes <jackpearkes@gmail.com>
* website: remove RC notification
* commmand/acl: fix usage docs for ACL tokens
* agent: remove comment, OperatorRead
* website: improve multi-dc docs
Still not happy with this but tried to make it slightly more informative.
* website: put back acl guide warning for 1.4.0
* website: simplify multi-dc page and respond to feedback
* Fix Multi-DC typos on connect index page.
* Improve Multi-DC overview.
A full guide is a WIP and will be added post-release.
* Fixes typo avaiable > available
In order to continue supporting the legacy ACL system, we replace
the 500 error from a non-existent `self` endpoint with a response of a
`null` `AccessorID` - which makes sense (a null AccessorID means old
API)
We then redirect the user to the old ACL pages which then gives a 403
if their token was wrong which then redirects them back to the login page.
Due to the multiple redirects and not wanting to test the validity of the token
before redirecting (thus calling the same API endpoint twice), it is not
straightforwards to turn the 'faked' response from the `self` endpoint
into an error (flash messages are 'lost' through multiple redirects).
In order to make this a slightly better experience, you can now return a
`false` during execution of an action requiring success/failure
feedback, this essentially skips the notification, so if the action is
'successful' but you don't want to show the notification, you can. This
resolves showing a successful notification when the `self` endpoint
response is faked. The last part of the puzzle is to make sure that the
global 403 catching error in the application Route also produces an
erroneous notification.
Please note this can only happen with a ui client using the new ACL
system when communicating with a cluster using the old ACL system, and
only when you enter the wrong token.
Lastly, further acceptance tests have been added around this
This commit also adds functionality to avoid any possible double
notification messages, to avoid UI overlapping
Alvin Huang