Handle Redirect

What exactly is a redirect?

A redirect is when the user is redirected to a different url. This is how the Oauth Flow is designed to work. After the user authenticates and grants permissions, the authorization server redirects the user to the redirect_uri with a code parameter in the url. Like this:

https://myapp.com/callback?code=xyz

We need that code parameter for the next step of the Oauth Flow.

Redirect vs. Callback: Terminology Clarification

In OAuth documentation and discussions, you'll often see the terms "redirect" and "callback" used interchangeably, which can be confusing. Here's how they relate:

• Redirect: This refers to the HTTP redirect action where the browser is sent from one URL to another. In OAuth, this happens when the authorization server sends the user back to your application.

• Callback: This refers to the URL in your application that receives the redirect. It's called a "callback" because it's the way the authorization server "calls back" to your application with the results.

• Redirect URI/URL: This is the address of your callback endpoint that you register with the OAuth provider.

So when we talk about "handling the redirect," we're really talking about having your application properly respond when the OAuth provider calls back to your registered URL with the authorization results. Both terms describe the same process from slightly different perspectives.

Redirects Must be Registered

You have to tell the Oauth App where to redirect the user after they authenticate and grant permissions. That redirect_uri is one of the pieces of information you have to register when you create the app. It has to be an HTTPS Url. Although in development you can often use http:// .

How to Handle the Redirect

Use a FileMaker Webviewer

Do the whole flow in a webviewer.

1. Take the user to layout or new card window with a webviewer on it.
2. Kick off the flow with step 1 of the Oauth Flow.
3. Wait for the redirect.

Poll the Webviewer

• Poll the web viewer with GetLayoutObjectAttribute() until the url changes. Parse it from the url.
• Use the OnPageChange script step to run a script to handle the redirect.

Use JavaScript

1. Use JavaScript in the Page you redirected to listen for the page load
2. Read the code parameter from the url
3. Use FileMaker.performScriptWithOption() to run a script and pass the code to it
4. The script can then run the next step of the Oauth Flow

Use OttoFMS

Wouldn't it be nice if you could just register a Script in your FileMaker File to handle the redirect? You can with OttoFMS.

You can Register a Redirect that points at your FileMaker File running on your server. It looks like this:

https://<server>/otto/redirect/fm/[filename]/[script-name]?arg1=[value1]&arg2=[value2]&...

The [filename] is the name of the FileMaker File. The [script-name] is the name of the script you want to run. The ?arg1=[value1]&arg2=[value2] is optional and you can pass arguments directly to the script. In the case of the Oauth Flow, the code parameter will be passed directly to the script as variable $code

Important notes:

• The current user must have the fmurlscript extended privilege.
• The file must be running on a FileMaker Server running OttoFMS 4.7 or greater

Here is the OttoFMS documentation for the Redirect feature:

https://docs.ottofms.com/ottofms-features/fm-file-redirect

Compare and Contrast

Web Viewer Approach vs OttoFMS Approach

When to Choose Each Approach

Choose Web Viewer when:

• You don't have OttoFMS available
• You need to support standalone FileMaker deployments
• You want to create a fully embedded authentication experience

Choose OttoFMS when:

• You have OttoFMS available on your server
• You want simpler implementation with fewer moving parts
• You prefer server-side processing for security reasons
• You need a more robust solution with less maintenance