Hi Sven, yes `session:` would be the ideal solution. But because it wasn't there (only getter) I wasn't sure whether this was a design decision - e.g. because sessions can't be reused.
Thanks! Peter On Tue, Nov 28, 2017 at 10:51 AM, Sven Van Caekenberghe <s...@stfx.eu> wrote: > Peter, > > > On 28 Nov 2017, at 10:42, Peter Uhnák <i.uh...@gmail.com> wrote: > > > > Hi, > > > > I have a scenario where I need to login to some web app and then reuse > the session/cookies in further requests. > > > > The basic approach (as presented in Enterprise Pharo book) works just > fine > > > > client := ZnClient new. > > > > client > > url: 'http://example.com/login'; > > formAt: 'username' put: 'john....@acme.com'; > > formAt: 'password' put: 'trustno1'; > > post. > > > > client > > get: 'http://example.com/my-file'. > > > > The problem is when I want to change the way response is retrieved. E.g. > > > > client > > accept: 'text/json'; > > contentReader: [ :entity | STON fromString: entity contents ]; > > get: 'http://example.com/some.json'. > > > > "uh-oh... it still uses STON contentReader" > > client > > get: 'http://example.com/homepage.html' > > > > > > Of course I could manually copy all the cookies, however I imagine there > is a better approach. Maybe injecting session from one ZnClient instance to > another? > > > > Thanks, > > Peter > > Reusing a ZnClient makes most sense when you access one host in a uniform > way. > > Like you say, there are different options > > - reset the content reader when needed (assign nil) > - make your content reader more intelligent (check the entity's content > type and act accordingly) > - get the #session from one client and use in on another one (#session: > must be added for this) > > ZnClient holds all kind of state (it is also a builder), so some > occasional resetting (or managing this state) can be needed. > > Does this help ? > > Sven > > >
