Logo
My Account |  Site Map | Contact Us  
Welcome Guest Search | Active Topics | Sign In | Register

Custom Cookies Options
GDargan
Posted: Thursday, August 13, 2015 7:32:17 PM
Rank: Member
Groups: Member

Joined: 8/8/2015
Posts: 12
Hello,

After some research on this forum, it appears that there are two ways to send custom cookies to webpages.

1) Handle the WebView.BeforeRequestLoad event with something resembling the following:

protected void OnBeforeRequestLoad(object sender, BeforeRequestLoadEventArgs
requestArgs)
{

requestArgs.Request.Cookies.Add(cookie);

}

2) Implement a custom ResourceHandler and insert the custom cookie in similar fashion to strategy 1.


I am having some issues successfully implementing both of these methods:

1. Handling the BeforeRequestLoad event is not getting me my desired results. The page loads as if the cookie was never sent.
2. When attempting to add a cookie to the CookieCollection through the ResourceHandler, every request is 'readonly'. What is going on here?

P.S. - Is there a way to make a custom session cookie with EO WebBrowser? If the Cookie.Expires property is left blank, does it default to a session cookie?

Thanks very much.
eo_support
Posted: Thursday, August 13, 2015 10:26:27 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 19,668
Hi,

OnBeforeRequestLoad is the correct way to attach cookies. You may want to use a traffic monitor to see whether the cookies have been correctly attached to the request.

You can not modify the request object through a custom ResourceHandler. A custom resource handler is a handler, it's where a request ends. As such you won't be able to modify the request and pass it down to someone else. You either pass it completely or take over completely.

Thanks!
GDargan
Posted: Friday, August 14, 2015 8:06:30 AM
Rank: Member
Groups: Member

Joined: 8/8/2015
Posts: 12
Thanks for your response. That's good to know about the Resource Handler.

How about session cookies? Is it possible to make one?

Thanks.
eo_support
Posted: Friday, August 14, 2015 3:05:50 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 19,668
Session cookie is just a cookie that your server application uses to identify your session. Your server can use any means to identify your session. For example, it can use a single huge cookie to store everything it needs to know, your session id, your user name, which page you have visited, etc. Or it can use other means to identify session without using cookie at all (for example, ASP.NET support cookieless session). Most web application use a dedicated cookie to identify session since it's easier to implement. However this is purely a matter of server side implementation. From the browser point of view, it have no idea what the server uses a cookie for. So there is no such thing as a "session cookie" for the browser engine. It just dutifully stores whatever cookies the server askes it store and send them back whenever a cookie matches a request and is not expired.
GDargan
Posted: Friday, August 14, 2015 3:47:45 PM
Rank: Member
Groups: Member

Joined: 8/8/2015
Posts: 12
I apologize if the specifics of my question were unclear. I am speaking of a cookie whose expiration date is 'session', instead of a fixed time period.
eo_support
Posted: Friday, August 14, 2015 4:57:48 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 19,668
What I was trying to tell you is "session" is a web server side concept. There is no such thing as "session" for a browser.
GDargan
Posted: Friday, August 14, 2015 7:38:09 PM
Rank: Member
Groups: Member

Joined: 8/8/2015
Posts: 12
I see - thanks.

I've looked over the web traffic and it appears that the required cookie is sent out correctly. Unfortunately, the site is still acting as if it is not receiving the cookie. Can you think of any other things that I can check?

Note that I am checking against another chrome-based .NET browser. This browser loads the site correctly.

Edit for more info: I'm calling 'document.cookie' to see what cookies the page has associated with it after the page loads. Of course, my custom cookie is not present as it is only sending the cookie out with each request. It is not caching the cookie locally. I believe the page I am attempting to load is determining whether the cookie is there through some AJAX processing. Therefore, it's getting the same result as I am.

Thanks.
eo_support
Posted: Monday, August 17, 2015 2:05:25 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 19,668
Hi,

OnBeforeRequestLoad would be called for every request, including your AJAX request, not just the main request. So if you attach your cookies there, they should go with your request.

If you continue to have problem, please try to isolate the problem into a test project and send the test project to us. See here for details on how to send us the test project:

http://www.essentialobjects.com/forum/test_project.aspx

Thanks!
GDargan
Posted: Monday, August 17, 2015 2:15:12 PM
Rank: Member
Groups: Member

Joined: 8/8/2015
Posts: 12
AJAX could/can access the cookies on a user's machine without making an HTTP request, correct?

For instance, a snippet of Javascript could call 'document.cookie', sift through the cookies cached in the user's browser, then dispatch an HTTP request based on the results of the sifting operation. I believe that this is what is going on here, which presents a problem with the way custom cookies are implemented in EO's framework. Custom cookies are 'tacked on' to requests instead of stored in the cache with other cookies.

In other WebBrowser frameworks I have used (Awesomium, DotNetBrowser), the framework gives access to the cookie cache. When a custom cookie is created, it is added directly to the cookie cache. You have a nice framework going here. It would be great to see this kind of functionality implemented.
eo_support
Posted: Monday, August 17, 2015 2:44:25 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 19,668
Hi,

AJAX does NOT have open access to cookies on a user's machine. Allowing so would be a serious security issue. If AJAX were allowed to access all the cookies, we would be able to write a page, put it on our server and get you to access it, then inside the page we could run JavaScript to collect your bank website's cookie and send it back to us, which would allow us to log into your bank's website as you ---- obviously this can't happen. The iron rule for cookie is a cookie is only sent back to a Url that it is explicitly associated to (this usually is the same site where the cookie comes from). Nobody else should have any mean to get cookies that don't belong to them. In this regard AJAX request is no different than a regular HTTP request. Indeed since both are just HTTP request and cookie is an HTTP matter.

For a browser engine, this rule is implemented and enforced by the cookie manager, traditionally called "cookie jar". For an embedder, there are two ways to extend the cookie manager. One is to allow user to explicitly add a cookie to the cookie manager --- usually you must set the scope of the cookie in this case (particular for which site/url it's valid) in order to avoid this cookie is sent to everyone. This method does not give you the control on a per-request level. This is probably the method that you are familiar with. Another method is what we use that allow you to precisely control which cookie is attached to which request.

We feel our model gives you more controls and is more secure and it should be ale to achieve whatever result you can achieve with other models. So we are not sure why it's not working for you. There might be certain ways that it is used in your application that we do not understand well enough --- that's why a test app would be very helpful in this case. If that can show us a different model would indeed be more appropriate, then we will be open to implement it differently as well.

Thanks!
Alexander
Posted: Wednesday, October 11, 2017 12:54:48 PM
Rank: Newbie
Groups: Member

Joined: 10/9/2017
Posts: 2
eo_support wrote:
Hi,

We feel our model gives you more controls and is more secure and it should be ale to achieve whatever result you can achieve with other models.

Thanks!


Excuse me, but "your model" does not prevent you to create alternative mechanism to setting up cookies.
Such a model forces you to investigate website structure in details and make tons of code that you cannot use in other solutions.

For example WebBrowser (IE).
To set cookie up we should do something like this:

Code: C#
[DllImport("wininet.dll", CharSet = CharSet.Auto, SetLastError = true)]
        internal static extern bool InternetSetCookie(string lpszUrl, string lpszCookieName, string lpszCookieData);

        InternetSetCookie("http://some.domain/someQuery, null, "cookieName=cookieData"); //it's not a mistake, we can set lpszCookieData with name and leave lpszCookieName with null or empty string.


Moreover, we can do this in any part of our code and at any time. And we care about cookies no longer and allow the browser to do its job. And we are happy!

In case of EO.WebBrowser I can use BeforeRequestLoad event or customResourceHandler for each WebView instance. Right?
And now I have to take care of every request in every WebView instance. Domain name? Current request? Should I use a cookie for this request? Content-Type? (yes, I don't want to use cookies fo javascript, styles and font requests, though I rarly must do it if server wants) "Accept" header? Oh nooo, again "*", etc..

As you can see - too many rules and all depends on circumstances. And with this approach i can't make universal solution. It would be nice to let the browser perform its task.


eo_support
Posted: Wednesday, October 11, 2017 1:04:42 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 19,668
We agree with you having one set of interface should not prevent supporting other interfaces. They are not mutually exclusive. Beside each interface having their advantages and disadvantages, some users also prefer to do things one way and other users would prefer to do things another way. So we are not against supporting multiple interfaces at all. What you are asking is another common way of doing things and it is a direct API to the "cookie jar". That is indeed on our list and we are hoping we can support it in the 2018 release cycle. It won't have the exact same programming interface but should follow the same concept.


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.