Member Avatar for kevindougans

Hi there,

Hope someone can help...

I'm developing a "Startpage" for a client's customers.

He wants all information relevant to his clients to be displayed on 1 web page.

We have come up with

All is well until we tried logging in to Novell Groupwise. It seems it won't accept logins from any location other than the login page they have created.

The original (and working) login page is here:

My question is... how can I include the original working login into our custom page at via an iframe that will automatically scroll away form all the junk on the original login page and just display the username and password box???

If that doesn't make sense let me know and I'll try re-clarify it but it looks understandable to me.

Thanks in advance,

Kevin

  • 2 Contributors
  • 1 Reply
  • 213 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by digital-ether

Dani AI

Generated

: embedding a remote GroupWise login inside your startpage usually fails because modern servers and browsers actively block framing and third‑party sessions. was right to raise cross‑domain issues — many sites send headers that forbid being framed, and modern cookie rules stop session cookies when content is loaded in a cross‑site iframe. (developer.mozilla.org)

Quick diagnostic checklist (do these first):

  • In your browser DevTools Network tab, load the GroupWise login URL and inspect response headers for X-Frame-Options or a Content-Security-Policy with frame-ancestors. If either forbids your origin, the page will refuse to render in an iframe. (developer.mozilla.org)
  • Inspect the Set-Cookie headers for the session cookie’s SameSite and Secure attributes; cookies set to block third‑party contexts will break logins inside an iframe. Recent browser behavior treats cookies without explicit SameSite conservatively. (web.dev)

If framing is blocked or cookies are suppressed, options are:

  • Use a supported integration (SSO, API or officially supported WebAccess options). Ask the GroupWise admin/vendor for supported integration methods rather than working around browser protections.
  • If you control both sides, a safer approach is to host a tiny login page on the same origin (or use a reverse proxy) so cookies and origin checks line up — but avoid storing or proxying credentials unless you understand the security and legal implications. (cheatsheetseries.owasp.org)

If you must coordinate UI between frames, prefer the standardized postMessage API over fragile hacks (cross‑origin calls must verify origin). Example pattern:

/* parent */
window.addEventListener('message', e => {
  if (e.origin !== 'https://trusted-gw.example') return;
  // handle e.data
});

/* iframe (trusted origin) */
parent.postMessage({ loggedIn: true }, 'https://your-startpage.example');

Use postMessage and strict origin checks rather than trying to manipulate a cross‑site iframe DOM. (developer.mozilla.org)

Security note: clickjacking headers and SameSite exist for user protection — bypassing them is risky and often impossible in modern browsers. If you need a reliable integration, pursue an official SSO/API route with the vendor. (cheatsheetseries.owasp.org)

Member Avatar for digital-ether

Hi there,

Hope someone can help...

I'm developing a "Startpage" for a client's customers.

He wants all information relevant to his clients to be displayed on 1 web page.

We have come up with

All is well until we tried logging in to Novell Groupwise. It seems it won't accept logins from any location other than the login page they have created.

The original (and working) login page is here:

My question is... how can I include the original working login into our custom page at via an iframe that will automatically scroll away form all the junk on the original login page and just display the username and password box???

If that doesn't make sense let me know and I'll try re-clarify it but it looks understandable to me.

Thanks in advance,

Kevin

You could move the scrollbar on the iframe to the position where it just shows what you want.
See: scrollTop and scrollLeft.

That would probably be the only solution if you cant edit the Groupwise page, or at least a page on that same domain. It may be that the Groupwise authentication first checks the http referer before authenticating.

If you can edit a page on that domain, just put the form there and try it out. If you can login from that page, then you can use that page to proxy over to the login page.
Just have your form action point to that page, then have that page generate a form with your login as hidden inputs and have javascript trigger the submit() on the form and send to Groupwise in another Iframe. That will post it to Groupwise and have groupwise login. Your proxy can then check based on the HTML of the page whether the login worked, and it can then reply to your original page via a javascript function like : top.loginResult(true||false);

The problem is the cross domain policy. You cant read the DOM of a child FRAME object if its on a different domain. But you can have that Iframe "talk" back to the parent by calling a javascript function in the parent once its loaded. It does this by referencing the parent as "top" and calling a function defined in the parent.

So you have your first iframe on the same domain as the login form, that is able to read the HTML of the login form, and is also able to talk back to the parent by invoking one of its javascript functions.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.