Login iframe using token from hydra

[MAX-786]

Fixes #6 Fixes #43 Needs #38 to be merged first.

Approach

In Volto-Hydra, Iframe component retrieves auth_token from redux store and listens to message event from frontend and sends back the token to it. When the user LOGIN/LOGOUT or token is RENEWED, volto updates the store with the updated token.

In hydra.js, it initiates the Bridge, and starts listening to the token response from the Hydra. It also have the method (getTokenFromCookies) to fetch the token from the cookies and pass it to the integrator to use it in the ploneClient.initialize().

How to Integrate your frontend

• Add 'hydra.js` in your frontend.
• Initialize the Bridge using initBridge method provided by './hydra.js', use 'https://hydra.pretagov.comfor optionadminOrigin` to tryout demo.
• Use the getToken() method provided by './hydra.js' to get the auth_token from Hydra. Use this in your plone client.
• At Volto-Hydra demo type in your hosted frontend url to preview public content and login to see the private pages.

Example Usage:

// nextjs 14
import ploneClient from "@plone/client";
import { useQuery } from "@tanstack/react-query";
import { initBridge } from "@/utils/hydra";

export default function Blog({ params }) {
  const bridge = initBridge("http://localhost:3000"); // Origin of your local Volto-Hydra
  const token = bridge._getTokenFromCookie();
  const client = ploneClient.initialize({
    apiPath: "http://localhost:8080/Plone/", // Plone backend
    token: token,
  });
  const { getContentQuery } = client;
  const { data, isLoading } = useQuery(getContentQuery({ path: '/blogs' }));

  if (isLoading) {
    return <div>Loading...</div>;
  }
  return (
    <div> {data.title}</div>
  )

[djay]

@MAX-786 the better way to deal with a PR that is dependent on another PR is to base the PR on that other PR. then the diffs show whats actually changed and it's obvious the relationship. It doesn't mean you have to merge this PR into the other one fist. Once the base PR is merged you just change the base of this PR again. it may even do that automatically if you delete that branch of the base PR.

[djay]

@MAX-786 this PR changes what an integrator is supposed to do with the API. So include the changes to the README with this PR. Keep them together. it's much easier to understand.

[djay]

More to that point, it's just as easy to read in a diff to the readme as it is in the comment on the PR. but the difference is you have to repeat it again anyway in the readme later so just put it there first. I am a believer in documentation driven development also. What this means is you try to write the documetnation first before you impliment the code. In this case it would mean the start of the PR is commits to change the README to show what you are about to implement. then implement. then make any tweaks to the readme at hte end. Why is this a good idea? Because it helps you focus on the user and your goal. In this case, even though the stories are written from editor perspective, your goal is to implement each editor function with the least lines of added integrator documenations as possible. The simplest and clearest set of instructions to add the required editor functionality. The more things that are automatic or optional the better. Optional means that you only have to do this more complicated API call to make the experience a bit better but the story is covered by doing nothing or something simpler.

by writing documentation first you often find that your first idea is not as simple as you thought when you try to explain how it will work in the documentation. So you then might change your approach before you write any code, saving time

[djay]

already got merged in via c4f12ecfde462bb2660679c7bc197b04da57ed36