Solved

Cloud MWO end points

  • 1 November 2022
  • 6 replies
  • 94 views

Userlevel 3
Badge +8

We are implementing MWO for our Cloud customer (21R2). Accessing MWO from outside the company network is of course necessary, but we have not been able to establish a controlled access. The documentation we followed is here: https://docs.ifs.com/techdocs/22r1/070_remote_deploy/090_exposing_to_internet/

We enabled the following endpoints at the network administration side:

Aurena Native    /mob/ifsapplications/projection/v1/MobileClientRuntime.svc/*
Aurena Native    /mob/ifsapplications/projection/v1/MobileAttachments.svc/*
Authentication    /auth

However, this was not enough. The MWO Maintenance application was not able to connect. Only after we enabled also the root directory (“/”) we successfully connected using the MWO app. But that also exposed the entire IFS Aurena client to outside network, so this is not acceptable.

Do you guys have experience of a clear set of endpoints that needs to be included so that MWO apps can access the environment?

icon

Best answer by Tuukka 9 November 2022, 12:40

View original

6 replies

Userlevel 3
Badge +5

you need to allow /mob/ifsapplications/* 

Userlevel 6
Badge +14

This is missing in the current documentations and we will update it to fix as you only need “/mob/ifsapplications/* ” to access native mobile

Userlevel 3
Badge +8

We already tried with having only “/mob/*” as the limiting factor, but that did not help. It seems like we need something else in addition to “mob” and “auth”?

Userlevel 6
Badge +14

‘Auth’ is common for both Native and web. We do not use any other end point apart from ‘mob’ and ‘auth’. But could this be because of the definition is incorrect in auth in the doc? Doc has the below definition. Did you try /auth/*?

Authentication /auth

Userlevel 6
Badge +14

Hi, Did you manage to resolve your issue? 

Userlevel 3
Badge +8

We finally managed to resolve this. The paths we used were:

/auth/

/mob/ifsapplications/

To clarify, their network software had a “Contains”-type validation for the HTTP requests, so we had to leave out the asterisks (*). In some other setup they might be necessary.

Thank you both for your help!

Reply