I have an application (VBS) that pulls data from a 3rd party web site via xmlhttp REST requests.
The first REST call of this application is to a log-in URL that returns also a JSESSIONID cookie ('Set-Cookie: JSESSIONID=7XYZD; Path=/; Secure; HttpOnly').
The called URL is 'https://www.bullionvault.com/secure/j_security_check?j_username=XXX&j_password=YYY'.
The second request, which needs me to be logged-in, pulls actual information from another URL of that web site, returning the data as XML document response as '.responseXML'. This flow works just fine if I execute the application while working on the VM (rdp), or also locally from my laptop.
Now, when I use a Azure Automation job to trigger the very same application on the VM the second (data) request does not return the expected XML document anymore; I get '200 OK' but then the (useless) log-in page of the site as HTTP document as the '.responseText'; '.responseXML' is empty.
Is seems that using an Azure Automation job is preventing the JSESSIONID from being sent back to the REST server when doing the data request. Hence, the server does not recognize me anymore, and send me back its log-in page. Note that there is no web browser involved explicitely.
Question: Is my suspicion of using Azure Automation breaking the application true; and how to fix this problem?
If you are using sandbox kind of setup instead of a hybird worker to execute then as the sandbox is a limited version of the Windows OS and user behavior like cookies and network configuration might not be the same so I would suggest trying out the hybrid worker (which runs under Local System context by default) to see if you can get some better-defined behavior.
Related
In our project we've built an Azure Function which launches Puppeteer in headless mode, goes to our webpage and takes a screenshot of the page which is then emailed out as pdf report. Works locally and deployed to Azure. That was the POC though. Now, we're moving to production and introduced authentication (Azure AD B2C, single tenant), will run each http request via APIM etc.
What happens now:
our Function app was registered in AD as a daemon and receives an access token.
this access token is inserted into 'Bearer ' Authorization header in Puppeteer (page.setExtraHTTPHeaders)
headless browser does not get authenticated and screenshot we receive is of the login screen (Azure SSO)
What needs to happen
we need to convince the react-msal library our FrontEnd is using to authenticate users, that the headless browser should get authenticated and allowed to render the page
The solution I've come up with so far is to replicate msal-react's logic of saving session information into Puppeteer's session storage, so that when msal-react checks for persisted session it will find it and allow headless chromium in. I'm yet to implement it. I'm curious if anyone in the community has experience building something similar.
I am building a webpage to be embedded as an Iframe App within Connections Cloud. It is based on the principals from this tutorial.
The webpage will be hosted on a server outside (of course) the collabserv.com domain. The purpose of the webpage is to interact (read/write) with Connections Cloud, using the SBT SDK, on behalf of the current Connections Cloud user.
The user is already authenticated with Connections Cloud, so I would not like there to be an extra login every time the Iframe App is loaded (making calls to Connections Cloud).
Since my webpage is located outside the Connections Cloud host/domain, it's not possible to reuse the user's existing authentication with the Connections Cloud server (?).
Any suggestions for solutions or workarounds?
BTW, my webpage will be hosted on a Domino server, but ideally there will be no user accounts on this server.
I was able to establish an authenticated connection with Connections Cloud using OAuth2. I more or less followed the OAuth2-steps described by Paul Bastide in this article.
All operations from start to the point where "code" is returned, are handled with XPages, reading QueryString for parameters etc. From that point (starting with "Open a Terminal Window" in the article), I programmed a Managed JavaBean that handles the rest of the OAuth-dribbeling.
When the access_token finally is received in my JavaBean, I use that to build a "Bearer authorization header" for an Apache HttpGet object. I then use the HttpGet object to query the Connections Cloud REST APIs.
We are implementing CA Site minder on external server for single sign on.
We did all necessary configuration on our server as well as on policy server.
When I hit my URL request get interrupted by ISAPI Filter and Site Minder Replace it with Log in Page Then I put credentials and click log in.
This request goes to policy server and after authenticating site minder redirect me to original url that I hit early on but somehow i am not getting SMSESSION Cookie.
I check FRT log and found that cookie is there in Request Header which mean site minder able to generate and pass the cookie to request but not set in Response header So its getting removed from response.
I tried to find why its getting removed or response not setting SMSESSION Cookie but not able to find any reason.
I am using Integrated pipeline mode and the same setup is working fine with classic mode but since my application is MVC I can't use that and i have to use integrated mode.
The SMSESSION cookie is not provided to the application from SiteMinder. It is initialized in the client browser after login and should be included when the authenticated request arrives back at your application.
I suggest monitoring the client side to ensure the SMSESSION is received after login and sent back out in the application request.
I am trying to access O365 site with Windows Live authentication from windows application. With Web Browser control I am able to do it. The problem is this tool runs for more than 15 hrs and within this time frame FedAuth cookies expires and I need to again refresh the cookies without bringing up the Web Browser control. And the other reason why I cannot have Web Browser control is that this application also supports windows service mode.
We have automated the ADFS authentication through Http Requests but for Windows Live authentication there are some javascript involved to actually do the login.
I have tried the SOAP approach mentioned here How to do Windows Live Authentication (RST) via SOAP, it returns the Request Security Token but it is not in the same format which ACS (Azure Control Service) returns.
Please suggest any work around or technique I can use to achieve this goal.
I am creating a web application that uses the Drupal 7 Content Management System. The web pages heavily use JQuery and AJAX.
The AJAX calls hit REST services, which are actually implemented using JAVA. Apache is running Drupal 7 and is configured to pass any calls to the REST urls through to the Java EE server (Jboss AS7). Everything is over SSL.
I need to Authorise and Authenticate calls to the REST services, and access the username or ID of the person currently logged-in to Drupal from the Java app. The question is... how...
As the AJAX calls are made to the same Apache server (rather than to a separate server etc), everything happens within the same http session, so I'm hoping this will be quite easy.
Things I've thought-of:
Configure a java security interceptor that calls a custom (locally
accessed only) drupal service that somehow reads the session id and
returns the logged-in username
create a "dumb" drupal REST service to act as a gateway for all of my REST calls, which authorises/ authenticates then injects the username before passing-through to the Java backend service
The article at https://lists.wisc.edu/read/messages?id=7777296#7777296 made me wonder if I could get-away with calling a Drupal service (just at the start of each Java service session) that takes a Drupal sessionID and returns the current user and his roles. I could configure it in my Java service so it would reperform this call every x seconds or y calls to check for role changes or logouts.
How does everyone else do it? This must be a common problem to solve isn't it? If not, what do you do instead to securely access authenticated services over AJAX? I'd rather not introduce a second user control process in addition to Drupal unless it's unavoidable. DRY :)
Thank you - this has me stumped!
Looking at what you are doing and trying to keep things as simple as possible, I would go for a variation of the first option. This is basically what the current node.js module does although it does it with unique authorization tokens. The workflow is something like this:
When a logged in user loads a page, a unique token is generated and stored in the Drupal database and sent to the browser
When the browser goes to connect to the node.js server it sends the auth token along with the request
The node.js server, upon receiving the request with token for the first time, will connect to a web service on the Drupal site and verify that the token is valid and send back any info about the user, and what roles/etc they have.
The node.js server then stores this internally for future requests, so that it doesn't have to ping the Drupal site for each request.
When a user logs out of Drupal, Drupal makes a direct request to the node.js server asking it to delete the token for that user.
Sounds like basically swapping your java app for node.js this should be pretty doable, with the advantage that it can scale well if you split this to multiple servers in the future.