>>20048551 (pb)

>third-party cookie

No.

You got a web service, as you would call it, running on intranet servers.

User logins to that service, session cookie is set.

Intranet web serice passes control over to an internet store, also sends over callback URL.

The user can now add items, and then checkout.

Now control is passed by OCI standard via official web standards to the caller via callback URL, which is the intranet site.

On modern browsers you don't get the previously set cookies anymore, that were set by the intranet site itself. You simply don't get them. They exist, but they are not passed, which is a violation.

You can open a new session and you get the cookies, but not when a internet site forwarded you to that intranet site.

And now of course no session is detected, and it goes back to a login, and therefore OCI data is also lost.

OCI is brilliant and simple. And these fuckers basically destroyed it.

Anyone on here with LWW medical journal access?

I need this here:

https://journals.lww.com/jcge/citation/1988/04000/about_this_issue.1.aspx#ContentAccessOptions

Journal of Clinical Gastroenterology 10(2):p 121-122, April 1988.

>>20048618

>I got fucked when they changed the behaviour of some event handlers

Properly written software does not do that.

>Until they break. You are being really optimistic now.

No, there are so called standard functions, that are meant to be called. They get specifically approved, you are meant to call them and they are static. Parameters will not change ever. Maybe new optional parameters may get added, but otherwise it will stay like that until the end of time.

Internally they may change something, but that never breaks anything, it's also properly tested.

It's actual business software, not hobby software. It's for critical infrastructure like oil platforms etc. you can't break shit on these and then go "oops"

>cookie secretly

What?

It's set by the intranet service. The intranet service passes control to an internet service, and then gets control back. And when it gets control back, the cookie is not sent out to the web browser, which is quite obviously meant to be a security feature.

The cookie wasn't deleted, it's not sent over in this specific case.

>>20048630

>not sent out to the web browser

*by

>>20048662

I need this article:

https://pubmed.ncbi.nlm.nih.gov/2901442/

Olsalazine as an alternative therapy in a patient with sulfasalazine-induced eosinophilic pneumonia

pubmed only has the abstract.

>>20048663

>From where does the cookie originate?

No, it's the cookie set by the intranet service. It's not 3rd party.

It's supposed to be there, but it's not sent over the line by the browser when forwarded from an internet server.

The web browser is supposed to save cookies and send them back to the server.

That's the point of them. And that's not done in this case.

>Whose intranet?

The intranet of the business I work for.

Intranet -internet -> intranet

Session data of intranet session saved in cookie, how it should be

it's simple.

>>20048682

I love you (no homo)

>>20048698

No, it's a web server running on an application server.

The web service is of course actively involved.

Web service -user says I want to get stuff from external source

Web service -forwards user to external URL

External URL -forwards back

Web service -who the fuck are you? What's wrong with your face/cookies?

>>20048698

>Sounds like it's your intranet that's dropping the cookie.

No.

The web browser even still has it.

The web browser just doesn't send it over after the forward by the external web service.

I can even view the cookie while the login screen is shown, it still exists on the browser.

It took me quite a bit of time to even figure out what's going on, especially because that session cookie isn't even set by the specific web service, but by the overall application server. It's how the application server figures out the user session.

>>20048736

The whole point of OCI is to get data FROM an external source into your local web service.

For example let's say you have a shopping system on the intranet, which allows users to order items from your own warehouse, but you also allow people to order a few extra items from an external provider.

Now you can either transmit the whole external catalog over night or whatever, which in some cases may be either impossible, or fully impossible in case the whole catalog is way too large, or you can use OCI and get order items that way from the external source and into your local shopping basket.

The whole point of OCI is to get data from one external source into a local system. The user is not supposed to really order directly from the external source, only ask for items from that external source and staff will then check the order that was made and process the whole order.

>If you got the cookie from the intranet server then it should still be valid in the web browser when you reconnect to the intranet server.

Correct.

And that's what they broke 1.5 years ago, or 2 years ago. I'm not sure.

When you get forwarded to a intranet URL from the internet, modern web browsers do not send you cookies anymore, at least for HTTP intranet sites.

>>20048679

This was also very useful, anon.

Not the article I asked for, but a similar one, which I missed in my (re)search.

Thank you!

>>20048782

>The cookie will be sent to the intranet when you connect back to it.

it should, but it doesn't.

>The URL in the browser's url bar will show the URL for the intranet server, right?

yes

> There's no reason to not send your session cookie to the server

potential hack / security related

"why would an external web site call an intranet site?????"

"this can only be a hacking attempt, we have to do something to stop it"

sai the web browser developers, who had no clue wtf they are doing.

>>20048802

>Is the external web page invoking the intranet address from Javascript?

No, via a HTTP redirection.

>What web browser?

Edge, Chrome, Firefox

They all do the same.

>third-party

It's not a third party cookie.

Again, the same site is called.

When I enter the URL manually, the cookie gets sent out.

It's a security "feature", which breaks standard.

>Do you even need to redirect from the external site?

It's irrelevant.

Control has to get passed back to the caller, and that doesn't work correctly anymore.

An iframe would just make matters worse, because the URL would still be the external site. It wouldn't change anything regarding cookies.