Jump to content

Web Viewer authentication not retained


Recommended Posts

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 by ESpringer
posted by accident, minor edits
Link to post
Share on other sites

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.

Link to post
Share on other sites

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 

Link to post
Share on other sites
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.

 

Link to post
Share on other sites
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.

Link to post
Share on other sites

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

Link to post
Share on other sites
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.

Link to post
Share on other sites
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 by comment
Link to post
Share on other sites
Posted (edited)

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 by ESpringer
fixed: note about precariousness credit goes to Wim
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Similar Content

    • By jaboda
      Hi,
      This is a peculiar bug which seems to have appeared with a recent Chrome update.
      Create a Web Viewer control with the following content:
      "data:text/html,<html><body bgcolor=\"#EEEEEE\">HELLO</body></html>" Then view the layout in WebDirect in Chrome. You'll notice it doesn't display anything. Remove the bgcolor and it works as expected. It also works in FileMaker.
      There are numerous workarounds but I can't find out how to fix it.
       
      Anyone else experienced this?
    • By jaboda
      This is a bit of a bizarre one which ate 90 minutes of my morning - so I thought I'd share it in case anyone else encounters it.
      One of our FileMaker use cases has an embedded web viewer displaying a Google Sheet (it's a runtime Kiosk app but the same issue applies to FMPro). This worked well and the users could update the spreadsheet (a rota).
       
      However this morning I noticed a strange bluey/grey overlay (see attachment). After quite a bit of digging it seems Adobe Flash is still installed in IE 11 and this was causing some form of issue.
      I disabled Flash in Group Policy (gpedit.msc) and the problem went away. There are other ways of disabling it which should also work.
      This was on Windows 10. I have now tested it on two machines so it should be fairly easily reproducible.
      I assume it's somehow caused by the 2nd October update to the Flash control.
      Anyway hope this helps if others have the same issue.

    • By Oyseka
      Hi All,
      I am viewing a records location through What3Words and the web viewer performs as expected on OS X 10.10.x and 10.11.x but when I put the file on OS X High Sierra the web viewer gives the error, "SSL Error, Unable to create a secure connection to the server". All connections are from the same location. Can anyone assist please
    • By TJ53
      I´m not sure why but the WV shows the correct result in some computers and devices, but in other just shows an empty page (please see attached file with WV including code).
      This is the result after testings:
      - It doesn't work on my Mac (10.11.06)
      - It works on my iPhone
      - It works on my iPad
      - I works on one of my colleague´s Mac (10.12 I believe)
      - It doesn't work on another collegue's Windows
       
      I have attached the file with the wv, is this working for you? any clue why this is happening? any help would be very much appreciated!!
       
      WV_Table.fmp12
    • By Franco Pagano
      When you have a webviewer in a layout as you change layout the webviewer reset it self, on mac activity app you can see the  webviewer process disappear.
      If the webviewer is in a popup  if you close the popup the process remain still up, you have to change layout if you want to close the webviewer process.
  • Who Viewed the Topic

    2 members have viewed this topic:
    Andreas T.  Walter-MainFrame 

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.