Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cookies can not be added in callback phase #48

Closed
GoogleCodeExporter opened this issue Mar 25, 2015 · 11 comments
Closed

cookies can not be added in callback phase #48

GoogleCodeExporter opened this issue Mar 25, 2015 · 11 comments

Comments

@GoogleCodeExporter
Copy link

Cookies and not be added to a response in the callback phase because there
is no response in the context.

A possible fix would be:
Add the cookies to the context. If there is a response in the context, add
them to the response, else add them to as a property. If the request
process is done the code returning the response queries the context.

Original issue reported on code.google.com by [email protected] on 4 Apr 2008 at 8:05

@GoogleCodeExporter
Copy link
Author

Original comment by [email protected] on 15 Jul 2008 at 9:22

  • Added labels: Priority-Critical
  • Removed labels: Priority-Medium

@GoogleCodeExporter
Copy link
Author

Does anybody see a better solution than the one outline in the original post? 
If not
I'll implement it because this functionality is critical.

Original comment by [email protected] on 15 Jul 2008 at 5:58

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

What about creating a response lazily, if none exists yet?

Original comment by renggli on 15 Jul 2008 at 6:46

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

It's tricky in any way. Looking at the senders of #redirectTo: which we should 
and
which we shouldn't catch. I think the only ones we should catch are:
- WARegistry >> #redirectResponseFor:
- WATask >> #updateRoot: (not sure)
- WARedirectHandler >> #redirectTo:
- maybe WARedirectContinuation

Original comment by [email protected] on 15 Jul 2008 at 7:26

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Original comment by [email protected] on 30 Aug 2008 at 4:02

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Original comment by [email protected] on 21 Sep 2008 at 5:48

  • Added labels: Milestone-2.9alpha
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Following discussion on mailing list, we don't think this is necessary for 
Alpha, but
would still be nice to have in 2.9.

Original comment by [email protected] on 4 Oct 2008 at 5:12

  • Added labels: Priority-Medium
  • Removed labels: Milestone-2.9alpha, Priority-Critical, Version-Seaside2.9

@GoogleCodeExporter
Copy link
Author

Just FYI on how I handle this in 2.8.  I just save up #onResponse: blocks on the
session and when returnResponse: finally runs I just run the response through 
any
stored blocks.  This let's me add cookies, or set status codes on the response 
during
the callback phase in my controller methods.  For example my Atom feed checks 
the
last updated header and issues a 304 and skips rendering if it hasn't changed.  
My
blog finds an old wordpress style url, parses it and does a 301 to the correct
shorter current url.  I've found it very handy to have direct access to the 
response
in my callbacks.

Original comment by [email protected] on 12 Jan 2009 at 3:21

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

We'll change that. Once Lukas returns from the Crusade of the Lost Changeset 
you'll 
have access to the response the in callback phase and can add headers and 
cookies if 
you feel like it.

We'll also try to get rid of the first redirect and add the session key to both 
the 
URL and the cookie of the first response. Once we get a session cookie from the 
client we drop it in the URL, JEE-style. Note you still won't see the session 
key in 
the browser bar if you have cookies enabled because the redirect URL after the 
first 
callback won't contain it anymore. That should also address Issue 19.

Original comment by [email protected] on 12 Jan 2009 at 5:36

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Original comment by [email protected] on 14 Jan 2009 at 10:51

  • Changed state: Started
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Finally done. Can be observed in the new WACookieFunctionalTest. Thanks Lukas 
for all
the work. Now there is only the session cookie left.

Name: Seaside-Tests-Functional-pmm.48
Author: pmm
Time: 22 January 2009, 10:49:59 pm
UUID: 0e88af6b-15c7-4b1a-99ef-18667dfff254
Ancestors: Seaside-Tests-Functional-jf.47

- don't do a redirect for adding cookies

Original comment by [email protected] on 22 Jan 2009 at 9:51

  • Changed state: Fixed
  • Added labels: Version-Seaside2.9
  • Removed labels: ****

dalehenrich added a commit to dalehenrich/Seaside that referenced this issue Sep 7, 2015
dalehenrich added a commit to dalehenrich/Seaside that referenced this issue Sep 7, 2015
…d use configuration: instead of project: ..
dalehenrich added a commit to dalehenrich/Seaside that referenced this issue Sep 7, 2015
…oject does not match the configuration name
dalehenrich added a commit to dalehenrich/Seaside that referenced this issue Sep 7, 2015
dalehenrich added a commit to dalehenrich/Seaside that referenced this issue Sep 7, 2015
dalehenrich added a commit to dalehenrich/Seaside that referenced this issue Sep 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant