Redirect Request: Vet Center QR code URL - ASAP target timing

[jilladams]

BLOCKED on WebOps: for subdomain > subdomain redirect, our attempted code change did not work. We will need WebOps to perform this redirect. WebOps ticket opened, TBD response.

Type of request

• [X] We are changing the URL of an existing page (complete redirect section)

Context

From Tiffany Lever via email to DaveC:

Recently, we came across a QR code that directs people to “Vet Centers are Here for you 24/7”. Since the QR code could continue to be out there and used, would it be possible to have https://www.vetcenter.va.gov/Vet_Centers_are_Here_For_You_24_7.asp be redirected to https://www.vetcenter.va.gov/? Thank you, let me know if there is anything I can do to help make this happen. Happy Friday and have a great day!

Implementation date

When does this request need to be live: no hard timing ASAP since fix for incorrect link in the wild

Redirects

Current URL	Redirect Destination or New URL
https://www.vetcenter.va.gov/Vet_Centers_are_Here_For_You_24_7.asp	https://www.vetcenter.va.gov/

FE Implementation notes

This will need to be done via client side redirect.

• We have confirmed that proxy-rewrite JS is being executed on vetcenter.va.gov.
• Please follow documentation for how to implement via client side redirects.

Process, Roles and Responsibilities

• [ ] Requesting team: Above information is provided
• [ ] Requesting team: All appropriate VA stakeholders are notified as appropriate
• [ ] IA: Request is vetted and documented and implementation plan is clear
• [ ] IA: Request is assigned to appropriate team for implementation
• [ ] Implementation team: Work is complete
• [ ] Implementation team: Validated in production
• [ ] Requesting team: Validates everything is correct in production and closes ticket

[mnorthuis]

Hi @jilladams @davidconlon - we don't usually get involved in legacy content to legacy content redirects, only those that involve our modernized pages. You can move forward on this as you see fit.

[jilladams]

Ah, didn't realize. Thanks Mikki!

[chri5tia]

PR: https://github.com/department-of-veterans-affairs/devops/pull/12277

Oops, wrong ticket. Disregard.

[jilladams]

Learned stuff with Dave's help:

• Redirect Implementation strategy (last update Jan 2020)
  • Lists subdomains where we can implement server-side redirects, and vetcenter.va.gov is not included in the list
  • How subdomain redirects work, including 2 notes:
    • "Option 3(?): Can a server-side redirect be implemented in Team Site?"
  • "For the majority of page-level redirects from subdomains (subdomain.va.gov), this is not feasible in the short term because it requires access to and relationships with technical stakeholders on the relevant teams. These contacts should be actively sought out via DEPO."

From va.gov-team/Web_Modernization_Run_Book.md at master · department-of-veterans-affairs/va.gov-team (github.com)

In cases where you are redirecting multiple pages considered more of a full website of pages, you will need to redirect at the server level. To accomplish this, you will need to engage the Web Operations team and have full authorization from the authorized owner of the website (e.g., VHA Digital Media). These considerations and steps are outlined below.

Thusly: have opened a ServiceNow ticket for WebOps help: https://yourit.va.gov/va?id=ticket&is_new_order=true&table=incident&sys_id=47f15a951bef555018da5316624bcbe1

(And: how to do that, if needed in future)

[jilladams]

Unassigning / removed from sprint, since this became a VA admin thing and not a PW code thing.

[jilladams]

We've opened a SNOW ticket with WebOps: https://yourit.va.gov/va?id=ticket&is_new_order=true&table=incident&sys_id=47f15a951bef555018da5316624bcbe1

[jilladams]

Updates:

1, I apparently didn't understand how to send a SNOW ticket to WebOps and have been asked to reassign it to WebOps. Figuring that out.

2, Meanwhile: Ryan and I re-reviewed the info around client side redirects. Some takeaways:

Client-side redirect is only possible if the proxy-rewrite JS is being executed on the relevant subdomain. In the case of vetcenter.va.gov, this subdomain has been added to support the injected header (here via what looks like a proactive effort to get our header on high priority subdomains). The header is in testing mode, visible on vetcenter.va.gov only when cookie is enabled.

This means:

1. Our proxy-rewrite JS is executing on the subdomain
2. We can do client-side redirect if that's the best thing to do. Caveat is that docs flag:
   • This is not ideal, as it depends on our JavaScript running correctly in order for a user to be redirected properly. It also depends on the legacy page staying live. Should be considered temporary solution.
   • If a page gets archived that has an existing client-side redirect, users may first see a 404 prior to the redirect executing. So if this page being redirected ever needs to be archived, that should actually be done via A) Replacing their page content with a 'redirect' message and B) Update their print materials and nav links with the new URL
3. Future work: we can / maybe should follow up with vetcenter subdomain owners about what it would take to turn on the injected header. Ticket cut for that: #11853 11853

@ryguyk could you update points here for your best guess, assuming we go the client-side redirect route? (Including testing, and debugging if it doesn't initially work, which seems possible.)

[jilladams]

Merged, leaving open to get verified in prod after deploy.

[jilladams]

Sad news, friends @jtmst @ryguyk : This redirect isn't working.

Verified that code is live in prod:

https://www.vetcenter.va.gov/Vet_Centers_are_Here_For_You_24_7.asp still lands / does not forward to the new URL.

Moving ticket back to Stretch, and we'll need to work out new approach. I'm gonna start by trying to figure out how to properly request something from WebOps via ServiceNow.

[jilladams]

Found a portal to make requests direct to WebOps instead of through ServiceNow: https://vaww.webops.va.gov/info/?get=catalog

Filed a redirect request there today. Will see what sort of response we get -- guessing prob not much in this holiday week, but tbd. Have also closed loop with stakeholder who made this request, and is 2ndary contact on the WebOps ticket.

Not sure if it's worth doing much more on our side here until we hear from them.

[jilladams]

Note: I can't find any artifact of the WebOps ticket. 🤷‍♀️ Didn't receive an email, and the WebOps ticketing UI did confirm successful submission, but I'm not finding any way to see my open issues. So: unclear if/when we may get traction on that.

[jilladams]

No news from WebOps ticket.

[jilladams]

New attempt:

Following steps from https://vaww.webops.va.gov/apps/kbx/kbarticle.cfm?get=2018-CST-0416041924, filed a new YourIT ticket to WebOps:

https://yourit.va.gov/va?id=ticket&is_new_order=true&table=incident&sys_id=00346bb71b806d10da76a798624bcb07

[jilladams]

The plot thickens: WebOps responded to our ticket:

WebOps only create site level redirects. Page level redirects are the site editor's responsibility. This is a TeamSite website and is supported by VA Web CMS Support VAWebCMSSupport@va.gov. Transferring to Sandeep Kotian/VA Web Solutions support for assistance.

The issue was reassigned to Sandeep, our TeamSite friend. Sandeep then referenced an index of site editors and asked Jenny Heiland-Luedtke. Deputy Director of VHA Digital Media, if someone within her group could manage this redirect, which they cannot.

Per discussion with Jenny:

• Confirmed that WebOps will only handle full site redirects, not one-off URL redirects
• She thought she recalled that the previous Public Websites team was able to do redirects to and from a subdomain. So we need to revisit what we know and understand exactly why we don't think we can execute on this. May be some disconnect with how we are understanding the previous team's documentation.

[jilladams]

After auditing existing docs, I don't find any indication that the PW team can directly implement a page-level redirect between 2 subdomain URLs. (In this case: both to/from are on the vetcenter.va.gov subdomain, powered by TeamSite, that does run our proxy-rewrite js but does not currently display the injected header.) These docs seem to indicate that: 1) page level redirects from a subdomain to va.gov must be done client side, if at all; 2) page level redirects within a subdomain weren't really considered or documented 3) there was some work remaining identified, to better understand how server-side redirects might be achieved for subdomains, which might solve this use case as well.

I'd feel better about that assessment if someone with a better working knowledge of reverse proxies and TICs reviewed docs #1 and #2 here to see if they agree.

And if so: my suggestion would be for me to email Sandeep Kotian, Brad Smelley, and Jenny H-L on the existing email thread with Tiffany Lever / Dave / @wesrowe to figure out how TeamSite folks can / can't help us.

Existing redirect documentation

1. Redirects

va.gov-team-sensitive/teams/vsa/teams/public-websites/redirects.md July 2021

Describes 3 types of redirect:

1. Same-domain redirect: from va.gov to www.va.gov — via revproxy-vagov redirects.yml file changes
2. vets.gov cross-domain redirect — from www.vets.gov to www.va.gov — via revproxy-vagov redirects.yml file changes
3. cross-domain redirect — from www.[subdomain].va.gov to va.gov — has 3 flavors: a. TeamSites which do not use the injected header — TeamSite folks must handle the redirect. b. TeamSites which use the injected header — redirect via vets-website/src/applications/proxy-rewrite/redirects/crossDomainRedirects.json. (Which we tried via PR 22944, and did not work.) c. Other sites that do not use the injected header — "You need to contact the Gateway Ops team. File an ESECC (Enterprise Security External Control Council)". We have not tried this route yet, nor did the old PW team, and it's described as a site-level redirect, rather than a page-level redirect.

2. Redirect Implementation Strategy

va.gov-team/platform/engineering/redirect-implementation-strategy.md Dec 2022 update from me; prior update = Jan 2020

4 types of redirects: 1) Server-side redirects within www.va.gov (link) 2) Client-side redirects within www.va.gov (link) 3) Server-side redirects from subdomains (subdomain.va.gov) (link) — used for full-site redirects 4) Client-side redirects for subdomains (subdomain.va.gov) (link) — used for page-level redirects. This is the same as 3b above, redirect via vets-website/src/applications/proxy-rewrite/redirects/crossDomainRedirects.json, which we tried and does not work for the redirect request in this ticket.

3. Redirects Strategy Suggestion

va.gov-team/vsp/teams/tools/frontend/redirects-strategy.md Feb 2019

Doc #2, Redirect Implementation Strategy, specifically notes that it replaces this doc.

4. Redirects

va.gov-team/platform/information-architecture/request-redirect.md April 2022

IA doc specific to requesting a redirect & vetting it.

5. Client-side and service-side redirect implementation process for Public Websites team

/va.gov-team/products/public-websites/content-team-processes/URL-redirect-process June 2020

Mostly an outdated workflow doc for an old PW team, that is replaced by doc #4 above, and should be updated or removed.

6. Client-side-redirects

/va.gov-team/products/public-websites/client-side-redirects Jan 2020

Stub doc with no details, should be deleted.

Other relevant docs

Reverse Proxy documentation

va.gov-team/platform/engineering/infrastructure/reverse_proxy.md

Docs to dos

• [ ] Consolidate Redirects info into Redirect Implementation Strategy
  • [ ] Remove contents of Redirects and point to Redirect Implementation Strategy
• [x] Mark Redirects Strategy Suggestion clearly as deprecated in favor of Redirect Implementation Strategy
• [x] Update title of the IA Redirects doc to be more clear about what it describes
• [x] Mark Client-side and service-side redirect implementation process for Public Websites team as deprecated or delete it altogether
• [x] Delete Client-side-redirects
• [x] Update current PW products doc Redirects section with better pointers to final updated docs

[jilladams]

@apisandipas @ryguyk FYI: Latest change in PR #23065 is merged / deployed, and redirect is still not working. Not urgent, as Dave has asked us to timebox this since it has sprawled. Maybe next week at onsite we can briefly chat at some point about how redirects and regroup.

[jilladams]

S76 sprint planning: the work to date has not successfully implemented a subdomain > subdomain redirect.

• WebOps will not act on this, as they only handle full-site redirects.
• TeamSites leaves redirects of this kind to the site owner, which is Vet Center folks in this case.
• Vet Center site admins from TeamSite are not able to implement this redirect, and asked Public Websites to handle (via phone call with Jenny H-L & Jill).
• Our front-end client-side changes have not so far been successful.

Per conversation with DaveC: we aren't able to spend more time on this right now. Low priority for this path, so we will not continue work here. We'll discuss next steps at the higher level subdomain > subdomain redirect level with DaveC and I'll close loop with the original requester, Tiffany, after that talk. Closing ticket.