URL query access from forge block

[kuon]

Is your feature request related to a problem? Please describe.
I am working on implementing an OpenID login block with forge. (block will be open source)

Describe the solution you'd like
I'd like to have access to the URL query parameters from my forge block. I think the best way to handle this would be to set an automatic variable. It should also work when Hide query params on bot start is set to true.

So I could do something like this:

    server: async ({
      credentials,
      options,
      variables,
    }) => {
        const url = variables.get("__URL__")
        // here url would contain the original url with all query parameters

[baptisteArno]

There is no way to do that, the execution is on the server where we don't have access to the URL query params 🙁

[kuon]

There is no way to do that, the execution is on the server where we don't have access to the URL query params 🙁

The proxy do forward the whole URL to the backend, so typebot should get it at some point. And if there is another API used (I noticed the call to startChat), the client could forward the query parameters to the server.

What I want to do can be done now with the set variable block with client side execution, but it is tedious for user to set up and require to disable the Hide query params setting on the bot.

Query parameters is a pretty standard way to "parametrize" an application and it seems that it could be something typebot supports out of the box.

[baptisteArno]

Can you tell me exactly what you are trying to do here?

[kuon]

Can you tell me exactly what you are trying to do here?

I am implementing an OpenID auth block. The idea is that you can add the block, configure it with an OpenID provider and give it a variable, and if the variable is populated, the user has been authenticated with the OpenID service.

But for this, I need to be able to access the query parameters that are added by the OpenID server when redirecting to typebot (especially code=...).

The flow is simple: OpenID block checks if there is a query parameter containing a code, if yes it validate that code with the configured OpenID server and set the configured variable with the username/email, if no, it redirects to the OpenID auth endpoint.

Usually, you put the OpenID block first in a flow, but this is not a requirement.

But it means that after the OpenID block, if the user variable is set to a value, you can trust this value.

[kuon]

I realized that typebot is sending the query variable as prefilledVariables to the startChat endpoint but it means that the user has to create all variables beforehand which would make my OpenID block hard to use as there are a handful of query parameters.

There is also a possibility that it might be a session variable as there is no way to determine the source of a variable. That's why it would be better to have a "hidden" variable that only code can use to make it cleaner.

[kuon]

My prototype works if the user creates the code and state variables beforehand, but this does not handle the possible errors.

[baptisteArno]

but it means that the user has to create all variables beforehand

But the variable is created since the user provides it to your OpenID config right? So if the variable has the same name as the query param the variable should be automatically populated

[kuon]

The user doesn't have to provide the variable names to the block, because those names are fixed.

To use the block, I have to instruct the user to create the following variables:

• code
• state
• error
• error_description
• error_uri

This is the first problem.

The second problem is that I cannot be sure that those variables are coming from the URL, for example, the user might have an error variable populated elsewhere. This makes the block brittle as it is hard to implement a good error logic. And as the OpenID blocks redirect the user, if the logic is not good, it can lead to an infinite redirect loop.

My suggestion is to add an __URL__ variable to all bots that is pre-exisiting with only code access (appears in variables.list() but not in UI). And to send it to typebot, it could simply be added to the prefilledVariables argument in startChat query.

The idea is similar to unix environment. Maybe other utility variables could come handy in the future, like the bot name or the user browser language whatever is relevant to the execution environment.

You could also prefer a single variable env: {url: "..."}, I am not familiar enough with typebot internals to advice what would be better.

The thing is, after having written a few forge plugins, I feel this would be a good approach. Also, I said "variable" but it could be another argument to the run function of the forge plugin, it doesn't really matter. I suggested the variable to reduce the work involved in adding this.

[baptisteArno]

Ok I see, thank you I will have to investigate :)