- Pharo-users - lists.pharo.org

Hacking a SOAP call - Checking a EU VAT number

by Sven Van Caekenberghe

We have no SOAP implementation in Pharo (yet). But that does not mean we cannot do simple SOAP calls. Here is a practical example: checking the validity of a EU VAT number. This is a public service offered by the EU through a SOAP API. The WSDL can be found here: http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl >From this we know that the endpoint is http://ec.europa.eu/taxation_customs/vies/services/checkVatService When you paste the WSDL URL in http://wsdlbrowser.com you can explore the API (this site parses the WSDL to reveal its contents). The call that we need is called 'checkVat'. We can copy the call template and POST it to the endpoint, manually. If we load the XML Parser, we can interpret the result. Here is the complete code: | xml result | xml := ZnEntity with: ( '<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="urn:ec.europa.eu:taxud:vies:services:checkVat:types"> <SOAP-ENV:Body> <ns1:checkVat> <ns1:countryCode>{1}</ns1:countryCode> <ns1:vatNumber>{2}</ns1:vatNumber> </ns1:checkVat> </SOAP-ENV:Body> </SOAP-ENV:Envelope>' format: #('LU' '20165772')) type: ZnMimeType applicationXml. result := ZnClient new url: 'http://ec.europa.eu/taxation_customs/vies/services/checkVatService'; entity: xml; contentReader: [ :entity | XMLDOMParser parse: entity contents ]; post. ((result allElementsNamed: 'checkVatResponse') first elementsCollect: [ :each | each name -> each contentString ]) asDictionary. => a Dictionary( 'address'->'31, RUE STE ZITHE L-2763 LUXEMBOURG' 'countryCode'->'LU' 'name'->'ITUNES S.A R.L.' 'requestDate'->'2015-03-03+01:00' 'valid'->'true' 'vatNumber'->'20165772' ) Of course, this will only work with simple SOAP interfaces. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

March 2, 2015

Re: [Pharo-users] Git (gitfiletree) on Pharo vs Windows

by Jan B.

Hello Thierry It works now, thank you a lot. It just seems like ProcessWrapper needs to be included also into MetaRepoForPharo40, but when I load ProcessWrapper separately from https://smalltalkhub.com/mc/hernan/ProcessWrapper/main , everything is fine on both Pharo 3 and 4 (40526). So only remaining minor windows problem (which probably is not on your side anyway) is that about getting gitfiletree repository address from string, so I have to add repository manually via monticello gui, but it does not matter too much. Jan Thierry Goubier wrote > Hi Jan, > > With HernÃ¡n's help and Dave Lewis confirmation, I have updated > GitFileTree so that it loads ProcessWrapper and wrote a solution to the > loading issue you have encountered. > > Please tell me any issues you would have with it. > > Thierry -- View this message in context: http://forum.world.st/Git-gitfiletree-on-Pharo-vs-Windows-tp4806791p4808994… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 2, 2015

Re: [Pharo-users] SQLite3 - External module not found

by Jeff Gray

Haha. Coolio. I'll keep using SQLite3 then :-) -- View this message in context: http://forum.world.st/SQLite3-External-module-not-found-tp4808734p4808993.h… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 2, 2015

roassal pixel rendering

by Peter UhnÃ¡k

Hi, I've been experiencing weird behavior with pixel rendering... basically one pixel lines will get blurred for some reason even though there is no half-pixel overlapping. Here is a test code (screenshots attached below). Without the labels the left box will be blurred while the right is better (even though it still has slight shadow); when I add labels however their behavior will switch. What I would expect is to have nice sharp lines all the time. Is this Athens issue? Roassal? Pharo? Its ugly both on Linux and Windows. ==================================== | view box1 box2 | view := RTView new. box1 := RTBox new width: 50; height: 51; fillColor: Color transparent; borderColor: Color black; elementOn: '50@51'. view add: box1. box2 := RTBox new width: 51; height: 50; fillColor: Color transparent; borderColor: Color black; elementOn: '51@50'. view add: box2. "box1 @ RTLabelled. box2 @ RTLabelled." box1 translateTo: -50 @ 0. box2 translateTo: 50 @ 0. view open ==================================== Peter

March 2, 2015

Re: [Pharo-users] Git (gitfiletree) on Pharo vs Windows

by Thierry Goubier

Hi Jan, With HernÃ¡n's help and Dave Lewis confirmation, I have updated GitFileTree so that it loads ProcessWrapper and wrote a solution to the loading issue you have encountered. Please tell me any issues you would have with it. Thierry Le 26/02/2015 11:06, Jan B. a Ã©crit : > Hi > > This time, when I add gitfiletree repository via monticello, it loads all > packages and classes. > However, it does not load any methods. Even if I use "Browse" in repository > window, it displays class definition, including variables and category > correctly, but still no methods. Normal filetree shows and loads these > methods. > > And another thing is that if I try to add and load gitfiletree repository > via following command, not GUI, I get an Error: filetree:// repository > 'C:\Users\User\Pharo\ourproject\repository\' does not exist > > command was: > > Metacello new > baseline: 'OurProject'; > repository: 'gitfiletree:///C:\Users\User\Pharo\ourproject\repository'; > load. > > when I delete that 'git' characters and leave just repository: > 'filetree:///C:\Users (etc.), it loads fine, too, but it may be my mistake. > > Jan > > > Thierry Goubier wrote >> Hi Jan, >> >> I pushed a new version (development) of GitFileTree using ProcessWrapper >> on Windows (version 82 on Smalltalkhub). >> >> You need to get ProcessWrapper loaded first, of course, from the >> Configuration browser in Pharo 3. >> >> If you want to try? >> >> Thierry > > > > > > -- > View this message in context: http://forum.world.st/Git-gitfiletree-on-Pharo-vs-Windows-tp4806791p4807789… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

March 2, 2015

Re: [Pharo-users] Zinc SSL Exception: decrypt failed code:5

by Sven Van Caekenberghe

> On 02 Mar 2015, at 12:46, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: > > Hi Sven, > > great - it works! Thank you very much for your help! You're welcome. BTW, a good bug report and a repeatible case makes all the difference. This is *very* important for us to make progress. > Regards > Sabine > > 2015-03-02 11:02 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]>: > Sabine, > > Here is a possible fix that works for me, this still has to be tested more broadly, but I think it will be good. Could you please try it by manually loading the package ? > > === > Name: Zodiac-Core-SvenVanCaekenberghe.36 > Author: SvenVanCaekenberghe > Time: 2 March 2015, 11:05:04.004975 am > UUID: 3e14e0cf-fe1a-42b9-b093-b5b2c2be09bf > Ancestors: Zodiac-Core-SvenVanCaekenberghe.35 > > Rewrite/refactoring of ZdcSecureSocketStream>>#fillBytes:startingAt:count: to fix an issue that occurred when reading a stream up to end. > > Note that some errors are now ignored the first time #decrypt:from:to:into: is called on left over data in the SSL session. > > Thanks Sabine Manaa for reporting this is issue. > === > > Sven > > > On 01 Mar 2015, at 16:54, Sabine Manaa <[hidden email]> wrote: > > > > Hi Sven, > > > > thanks for the explanation. If the problem would be in Smalltalk I could _try_ to find a solution but I am not able to go into primitives. > > > > Concerning my workaround: > > If remove the line where the exception is thrown in >>fillBytes:startingAt:count: > > "processedCount < 0 ifTrue: [ ^ self sslException: 'decrypt failed' code: processedCount ]." > > > > Then it works. So, it seems that ignoring the exception would fix the problem for me: > > > > [| theZnClient | > > theZnClient := ZnClient new > > systemPolicy ; > > https; > > host: 'user.gini.net'; > > path: 'oauth/token?grant_type=client_credentials'; > > username: 'spesenfuchs' password: 'asdf'; > > accept: ZnMimeType applicationJson; > > get. ] on: Error > > do: [ :ex | ex resume ]. > > > > But this needs that the exception is resumable. > > > > So could you perhaps make the exception resumable? > > > > ZdcSecureSocketStream>>sslException: text code: code > > self error: > > (String streamContents: [ :stream | > > stream << 'SSL Exception: ' << text << ' [code:'. > > stream print: code. > > stream << ']' ]) > > > > >>error: uses Error and this is not resumable. > > > > Could you make the Exception resumable? > > Then perhaps Johan could use resume, to? > > > > What is your opinion about this? Do I miss something here? > > > > Regards > > Sabine > > > > > > > > > > 2015-03-01 14:12 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]>: > > > > > > On 01 Mar 2015, at 13:14, Sabine Manaa <[hidden email]> wrote: > > > > > > Excuse the silly question but what exactly is a plugin? Is it the code which is called by the primitive? The problem is not within the pharo code itself, right? It is the result of the primitive, which is wrong, right? > > > > Yes, we're talking about primitives. Plugins group primitives, some plugins are builtin, others are more like dynamic libraries, and live separate from the VM. > > > > The problem is that the C and OS implementations are different for each platform. Which can result in very subtle semantic differences. In this case it has something to do with detecting/handling a closed socket stream. > > > > > Can I do something more to solve the problem or should I try to write a workaround for me (exception handler and grab the result of the request)? > > > > From a user standpoint, no. We have a reproducible case now. Thanks for that. > > > > I am indeed afraid that you might need to think about a workaround, I can't promise anything about fixing this. Of course, anyone is free to help. > > > > Sven > > > > > Regards > > > Sabine > > > > > > > > > Am Sonntag, 1. MÃ¤rz 2015 schrieb Sven Van Caekenberghe : > > > Arg, and on Linux it works too. > > > > > > Below the image layer, the normal Pharo code that we see, both the Socket plugin and the SSL plugin are three totally different implementations. This is really frustrating. The Mac code originates from *before* Mac OS X came on the scene ! Today, Mac OS X could probably use 99% of the Linux version. > > > > > > > On 01 Mar 2015, at 10:29, Sabine Manaa <[hidden email]> wrote: > > > > > > > > > > Hi, > > > > > > > > I tried on Windows, there it works. > > > > > > > > Sabine > > > > > > > > > > > > > > > > -- > > > > View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… > > > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > > > > > > > > If you reply to this email, your message will be added to the discussion below: > > http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… > > To start a new topic under Pharo Smalltalk Users, email [hidden email] > > To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here. > > NAML > > > > > > View this message in context: Re: Zinc SSL Exception: decrypt failed code:5 > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… > To start a new topic under Pharo Smalltalk Users, email [hidden email] > To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here. > NAML > > > View this message in context: Re: Zinc SSL Exception: decrypt failed code:5 > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 2, 2015

Re: [Pharo-users] SQLite3 - External module not found

by phil＠highoctane.be

Hey, I hope not, as they are not working the same way and the SQLite3 thing is now working okay. Phil On Mon, Mar 2, 2015 at 1:04 PM, Jeff Gray <jeff(a)rogerthedog.com> wrote: > Is your intention that NBSQLite3 will replace SQLite3 in the Pharo > Configuration Browser at some point? > > > > > > -- > View this message in context: http://forum.world.st/SQLite3-External-module-not-found-tp4808734p4808825.h… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

March 2, 2015

Re: [Pharo-users] SQLite3 - External module not found

by Jeff Gray

Is your intention that NBSQLite3 will replace SQLite3 in the Pharo Configuration Browser at some point? -- View this message in context: http://forum.world.st/SQLite3-External-module-not-found-tp4808734p4808825.h… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 2, 2015

Re: [Pharo-users] Zinc SSL Exception: decrypt failed code:5

by Sabine Manaa

Hi Sven, great - it works! Thank you very much for your help! Regards Sabine 2015-03-02 11:02 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] < ml-node+s1294792n4808807h12(a)n4.nabble.com>: > Sabine, > > Here is a possible fix that works for me, this still has to be tested more > broadly, but I think it will be good. Could you please try it by manually > loading the package ? > > === > Name: Zodiac-Core-SvenVanCaekenberghe.36 > Author: SvenVanCaekenberghe > Time: 2 March 2015, 11:05:04.004975 am > UUID: 3e14e0cf-fe1a-42b9-b093-b5b2c2be09bf > Ancestors: Zodiac-Core-SvenVanCaekenberghe.35 > > Rewrite/refactoring of ZdcSecureSocketStream>>#fillBytes:startingAt:count: > to fix an issue that occurred when reading a stream up to end. > > Note that some errors are now ignored the first time > #decrypt:from:to:into: is called on left over data in the SSL session. > > Thanks Sabine Manaa for reporting this is issue. > === > > Sven > > > On 01 Mar 2015, at 16:54, Sabine Manaa <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=4808807&i=0>> wrote: > > > > Hi Sven, > > > > thanks for the explanation. If the problem would be in Smalltalk I could > _try_ to find a solution but I am not able to go into primitives. > > > > Concerning my workaround: > > If remove the line where the exception is thrown in > >>fillBytes:startingAt:count: > > "processedCount < 0 ifTrue: [ ^ self sslException: 'decrypt failed' > code: processedCount ]." > > > > Then it works. So, it seems that ignoring the exception would fix the > problem for me: > > > > [| theZnClient | > > theZnClient := ZnClient new > > systemPolicy ; > > https; > > host: 'user.gini.net'; > > path: 'oauth/token?grant_type=client_credentials'; > > username: 'spesenfuchs' password: 'asdf'; > > accept: ZnMimeType applicationJson; > > get. ] on: Error > > do: [ :ex | ex resume ]. > > > > But this needs that the exception is resumable. > > > > So could you perhaps make the exception resumable? > > > > ZdcSecureSocketStream>>sslException: text code: code > > self error: > > (String streamContents: [ :stream | > > stream << 'SSL Exception: ' << text << ' [code:'. > > stream print: code. > > stream << ']' ]) > > > > >>error: uses Error and this is not resumable. > > > > Could you make the Exception resumable? > > Then perhaps Johan could use resume, to? > > > > What is your opinion about this? Do I miss something here? > > > > Regards > > Sabine > > > > > > > > > > 2015-03-01 14:12 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] > <[hidden email]>: > > > > > On 01 Mar 2015, at 13:14, Sabine Manaa <[hidden email]> wrote: > > > > > > Excuse the silly question but what exactly is a plugin? Is it the code > which is called by the primitive? The problem is not within the pharo code > itself, right? It is the result of the primitive, which is wrong, right? > > > > Yes, we're talking about primitives. Plugins group primitives, some > plugins are builtin, others are more like dynamic libraries, and live > separate from the VM. > > > > The problem is that the C and OS implementations are different for each > platform. Which can result in very subtle semantic differences. In this > case it has something to do with detecting/handling a closed socket stream. > > > > > Can I do something more to solve the problem or should I try to write > a workaround for me (exception handler and grab the result of the request)? > > > > From a user standpoint, no. We have a reproducible case now. Thanks for > that. > > > > I am indeed afraid that you might need to think about a workaround, I > can't promise anything about fixing this. Of course, anyone is free to > help. > > > > Sven > > > > > Regards > > > Sabine > > > > > > > > > Am Sonntag, 1. MÃ¤rz 2015 schrieb Sven Van Caekenberghe : > > > Arg, and on Linux it works too. > > > > > > Below the image layer, the normal Pharo code that we see, both the > Socket plugin and the SSL plugin are three totally different > implementations. This is really frustrating. The Mac code originates from > *before* Mac OS X came on the scene ! Today, Mac OS X could probably use > 99% of the Linux version. > > > > > > > On 01 Mar 2015, at 10:29, Sabine Manaa <[hidden email]> wrote: > > > > > > > > > > Hi, > > > > > > > > I tried on Windows, there it works. > > > > > > > > Sabine > > > > > > > > > > > > > > > > -- > > > > View this message in context: > http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… > > > > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > > > > > > > > > > > > > > If you reply to this email, your message will be added to the discussion > below: > > > http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… > > To start a new topic under Pharo Smalltalk Users, email [hidden email] > > To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click > here. > > NAML > > > > > > View this message in context: Re: Zinc SSL Exception: decrypt failed > code:5 > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… > To start a new topic under Pharo Smalltalk Users, email > ml-node+s1294792n1310670h65(a)n4.nabble.com > To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 2, 2015

Re: [Pharo-users] Zinc SSL Exception: decrypt failed code:5

by Sven Van Caekenberghe

Sabine, Here is a possible fix that works for me, this still has to be tested more broadly, but I think it will be good. Could you please try it by manually loading the package ? === Name: Zodiac-Core-SvenVanCaekenberghe.36 Author: SvenVanCaekenberghe Time: 2 March 2015, 11:05:04.004975 am UUID: 3e14e0cf-fe1a-42b9-b093-b5b2c2be09bf Ancestors: Zodiac-Core-SvenVanCaekenberghe.35 Rewrite/refactoring of ZdcSecureSocketStream>>#fillBytes:startingAt:count: to fix an issue that occurred when reading a stream up to end. Note that some errors are now ignored the first time #decrypt:from:to:into: is called on left over data in the SSL session. Thanks Sabine Manaa for reporting this is issue. === Sven > On 01 Mar 2015, at 16:54, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: > > Hi Sven, > > thanks for the explanation. If the problem would be in Smalltalk I could _try_ to find a solution but I am not able to go into primitives. > > Concerning my workaround: > If remove the line where the exception is thrown in >>fillBytes:startingAt:count: > "processedCount < 0 ifTrue: [ ^ self sslException: 'decrypt failed' code: processedCount ]." > > Then it works. So, it seems that ignoring the exception would fix the problem for me: > > [| theZnClient | > theZnClient := ZnClient new > systemPolicy ; > https; > host: 'user.gini.net'; > path: 'oauth/token?grant_type=client_credentials'; > username: 'spesenfuchs' password: 'asdf'; > accept: ZnMimeType applicationJson; > get. ] on: Error > do: [ :ex | ex resume ]. > > But this needs that the exception is resumable. > > So could you perhaps make the exception resumable? > > ZdcSecureSocketStream>>sslException: text code: code > self error: > (String streamContents: [ :stream | > stream << 'SSL Exception: ' << text << ' [code:'. > stream print: code. > stream << ']' ]) > > >>error: uses Error and this is not resumable. > > Could you make the Exception resumable? > Then perhaps Johan could use resume, to? > > What is your opinion about this? Do I miss something here? > > Regards > Sabine > > > > > 2015-03-01 14:12 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]>: > > > On 01 Mar 2015, at 13:14, Sabine Manaa <[hidden email]> wrote: > > > > Excuse the silly question but what exactly is a plugin? Is it the code which is called by the primitive? The problem is not within the pharo code itself, right? It is the result of the primitive, which is wrong, right? > > Yes, we're talking about primitives. Plugins group primitives, some plugins are builtin, others are more like dynamic libraries, and live separate from the VM. > > The problem is that the C and OS implementations are different for each platform. Which can result in very subtle semantic differences. In this case it has something to do with detecting/handling a closed socket stream. > > > Can I do something more to solve the problem or should I try to write a workaround for me (exception handler and grab the result of the request)? > > From a user standpoint, no. We have a reproducible case now. Thanks for that. > > I am indeed afraid that you might need to think about a workaround, I can't promise anything about fixing this. Of course, anyone is free to help. > > Sven > > > Regards > > Sabine > > > > > > Am Sonntag, 1. MÃ¤rz 2015 schrieb Sven Van Caekenberghe : > > Arg, and on Linux it works too. > > > > Below the image layer, the normal Pharo code that we see, both the Socket plugin and the SSL plugin are three totally different implementations. This is really frustrating. The Mac code originates from *before* Mac OS X came on the scene ! Today, Mac OS X could probably use 99% of the Linux version. > > > > > On 01 Mar 2015, at 10:29, Sabine Manaa <[hidden email]> wrote: > > > > > > > Hi, > > > > > > I tried on Windows, there it works. > > > > > > Sabine > > > > > > > > > > > > -- > > > View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… > > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… > To start a new topic under Pharo Smalltalk Users, email [hidden email] > To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here. > NAML > > > View this message in context: Re: Zinc SSL Exception: decrypt failed code:5 > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 2, 2015