Web Viewer authentication not retained

[ESpringer]

Dear FMForums folk,

I'm a long-time personal user, building and working out of my own solutions. (I used to post here often, but for years now have been happily using rather than designing...)

One of my databases uses FM web viewers as a front-end for my university's moodle (cms platform), tunneling in based on various URLs for students, assignments, etc. 

In the past, a cms like moodle (and before it we had BlackBoard) would need me to authenticate once, and then all subsequent url queries within a session were served up properly, just as if I were using an ordinary browser.

With more recent versions of moodle, suddenly authentication fails to survive any transitions at all (from one tab to another, from one record to another, toggling into layout mode and back). It's as if the browser session resets with every step of my workflow. 

I've just upgraded to FM19 and delayed posting to see if that would help, but I'm still getting the constant authentication roadblocks. 

What's preventing FileMaker from retaining authentication via PHP in the way that browsers do?

(I'm running on Mac OS 10.14/Mojave, so it's emulating safari, yes? But Safari itself is having no trouble.)

Many thanks for any ideas!

 

Edited June 13, 2020 by ESpringer
posted by accident, minor edits

[Wim Decorte]

It's not really emulating a browser, it uses the underlying 'engine' if you will that the OSes exposes.  In that sense web viewers are not full-fledged browsers.  Many systems (and perhaps moodle as well) can detect whether the connection comes from a real browser or from an in-app web widget like the web viewer is and will explicitly put extra security restrictions on it.  Sort of like what many sites do when they detect they are being targeted through an iFrame (a web page within a web page).

If you need heavy interaction with moodle, have FM open the real browser.  Or use the moodle APIs to interact with its data.

[ESpringer]

Wim, your reply is so helpfully informative.

A bit devastating though. I've poured so many hours, over many years, into developing these solutions to get around the fact that the browser-interface for the CMS requires too many point-and-click navigation steps to achieve what a simple scroll through records or shift of tabs should (and did) do with FM's help (using calc fields to swap in various bits of the relevant urls). 

The idea of using moodle's API to interact with data sounds like it would require me to learn a whole new domain of programming skills. 

I think I'll go cry into my beer now. 

-ESpringer 

[comment]

2 hours ago, ESpringer said:

suddenly authentication fails to survive any transitions at all (from one tab to another, from one record to another, toggling into layout mode and back).

Maybe you could eliminate those transitions by keeping the window with the web viewer on the same layout and on the same record at all times and doing all the necessary navigation through portals or other windows. And there certainly is no call for toggling into layout mode in the course of normal use.

 

[Wim Decorte]

55 minutes ago, ESpringer said:

The idea of using moodle's API to interact with data sounds like it would require me to learn a whole new domain of programming skills. 

Not different programming skills, just using the same old FM script steps and functions that are available.

You'll find it surprisingly easy and extremely rewarding to learn how to interact with REST APIs.  There are a ton of resources in the FM community on how to do this and of course you can ask any and all questions here.

[ESpringer]

Wim and Comment, thanks for the supportive comments... 

I'm afraid design consolidation can't help; the problem is actually not just with record/layout/mode changes; it's that my SSO authentication just doesn't *carry* at all from any instance of a web viewer to any other instance.

For example: On my wide screen, one layout has 2 web viewers side-by-side, for the first and second page of a history overview (that moodle stubbornly paginates, tho 2 pages almost always suffices). Now, when I authenticate through the first web viewer, the url&"&page=1" variant -- on the very same record and layout — remains locked out. (This wasn't true in earlier versions of moodle; I'd authenticate once and then everything would behave, and I could then scroll through student records pre-populated with calculated urls tuned to the relevant API variables.) 

I'm heartened that you're confident that learning about API to retrieve data directly is not too steep a learning curve... but I do have a day job  .

Also I hate to reinvent the wheel in terms of building that data back into friendly shapes. (Am I right that a direct API query would get me things like id-number-date arrays, but I'd have to put work into making them visually digestible?)

For example: moodle's web interface already does serve up perfectly adequate graphs for each student's participation in activity X over time. This visual display over the web (once you're at the url) is a helpfully pre-invented wheel; it's the navigation that's the devil. On an ordinary browser, one has to navigate to the participants list, point-and-click to select a student, and then drill down among available reports and logs for a given student, squinting at drop-down menus to filter the desired info, etc., and then back out and do it all. over. again. for the next student.

Once I had parsed the url structure of this or that "perfect report" for my purposes, FM's web viewers used to let me scroll through student records, glancing at each graph, already tuned to the variables I care about.

While learning direct API queries could give me much more power in some ways (once I get over the intimidation), it seems that certain "it just works" experiences are a thing of the past because of this tightened security around web viewer "widgets"... is that right? 

(Is there any imaginable workaround?)

-ESpringer

[Wim Decorte]

5 minutes ago, ESpringer said:

Once I had parsed the url structure of this or that "perfect report" for my purposes, FM's web viewers used to let me scroll through student records, glancing at each graph, already tuned to the variables I care about.

The crux is in this paragraph: your solution depends on behavior of two entities over which you have very little control.  Moodle does not expect nor support people using their URL structure in the way you have done.  That's what their APIs are for.

Likewise: the behavior of the web viewer is subject to change because it depends on that underlying engine and ever-evolving security considerations.

So you were always walking a tightrope with a lot of inherent brittleness: any update on their end would break things.  Without notice because their URL structure is not a 'feature'.  Whereas with APIs there would be both ample warning and a decent period of backward compatibility.

[comment]

33 minutes ago, ESpringer said:

my SSO authentication just doesn't *carry* at all from any instance of a web viewer to any other instance.

Well my suggestion was to stick to a single instance of web viewer throughout your session. If you need to move to another page but wish to continue viewing the current page, try storing the current page's contents in a variable and showing it in a field or another web viewer - one that does not require logging into the CMS system.

Of course, this is no more than a workaround and depending on the complexity of your current solution may require considerable work. If your CMS offers an alternative access through an API, your time may be better spent exploring that alternative.

 

Edited June 13, 2020 by comment

[ESpringer]

Thanks, both, again.

To be clear, poking around within a single web viewer session has no appeal in this situation, because that single web viewer window would have virtually none of the power of filemaker that my existing solution is intended to harness, and also none of the conveniences of a dedicated web browser.   

So it's API or bust. The learning curve looks like the kind of work that would pay off at scale, but a bit steep for someone for whom FM has been not a career but something between a workflow convenience and a creative-procrastination hobby. (And of course these direct API queries will need to clear authentication too, and if I run into headaches there, I'm likely to be always unsure whether the problem is my own incompetence.)

At least, as Wim points out, if I do invest time in setting up tools to pull data into filemaker using moodle's API, the resulting solution will not be so "off-label" as to be perennially precarious. 

-ESpringer

Edited June 13, 2020 by ESpringer
fixed: note about precariousness credit goes to Wim