Using www.seasidehosting.st - how do I send out emails for authenticating
users from seaside? It works fine on my own machine smpting via my ISP but it blocks relayed emails when I run it on www.seasidehosting. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
2007/10/12, Robert Hawley <[hidden email]>:
> Using www.seasidehosting.st - how do I send out emails for authenticating > users from seaside? It works fine on my own machine smpting via my ISP but > it blocks relayed emails when I run it on www.seasidehosting. What smtp host do you use? Cheers Philippe > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by rhawley
Hi
It's a blueyonder account - it requires smtp authentication when connected to from other networks. Is there a way of doing remote smtp authentication from within squeak? I note too that seasidehosting.st does not allow use of 'random' ports - although I don't know if there are any non-random ports (or if that is a factor). How do others get around this? I assume that they have to use a non-authenticating server. Yours Bob 2007/10/12, Robert Hawley <rhawley at plymouth.ac.uk>: > Using www.seasidehosting.st - how do I send out emails for authenticating > users from seaside? It works fine on my own machine smpting via my ISP but > it blocks relayed emails when I run it on www.seasidehosting. What smtp host do you use? Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by rhawley
>>>>> "Robert" == Robert Hawley <[hidden email]> writes:
Robert> Using www.seasidehosting.st - how do I send out emails for Robert> authenticating users from seaside? It works fine on my own machine Robert> smpting via my ISP but it blocks relayed emails when I run it on Robert> www.seasidehosting. I'm kinda happy that a free hosting site doesn't let you send arbitrary mails. Otherwise, it would quickly become a spam source, which would in turn get it shut down or at least RBLed right away as a spam source. Spam sucks. It has ruined the path that got us here, in ways that make it difficult to move forward. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by rhawley
Hi
Are you saying that it is policy of seasidehosting not to allow email authentication? They do not state it as such on their site. Authentication is a fairly basic server-side necessity and it is difficult to do much worth doing with seaside without having some way of identifying users. Yours Bob ________________________________________ From: Randal L. Schwartz [[hidden email]] Sent: 14 October 2007 17:09 To: Robert Hawley Cc: [hidden email] Subject: Re: [Seaside] Emailing out >>>>> "Robert" == Robert Hawley <[hidden email]> writes: Robert> Using www.seasidehosting.st - how do I send out emails for Robert> authenticating users from seaside? It works fine on my own machine Robert> smpting via my ISP but it blocks relayed emails when I run it on Robert> www.seasidehosting. I'm kinda happy that a free hosting site doesn't let you send arbitrary mails. Otherwise, it would quickly become a spam source, which would in turn get it shut down or at least RBLed right away as a spam source. Spam sucks. It has ruined the path that got us here, in ways that make it difficult to move forward. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> Are you saying that it is policy of seasidehosting not to allow email
> authentication? They do not state it as such on their site. Authentication > is a fairly basic server-side necessity and it is difficult to do much worth > doing with seaside without having some way of identifying users. How do you want to do authenticated SMTP? I guess Squeak does not support that by default. As far as I remember, seasidehosting.st allows to send a limited number of mails trough localhost. This is also what the management application is doing (which itself is hosted on seasidehosting.st). Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by rhawley
Hi Lukas I guess authenticated SMTP means sending a name and password to the ISP via an agreed protocol - if someone thinks it possible and worth doing I think it would be useful. Do you know how to send emails through localhost in the way you suggest? Yours Bob --- >How do you want to do authenticated SMTP? I guess Squeak does not >support that by default. >As far as I remember, seasidehosting.st allows to send a limited >number of mails trough localhost. This is also what the management >application is doing (which itself is hosted on seasidehosting.st). >Cheers, >Lukas _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Hi guys!
Squeak supports authenticated SMTP - we use it in Gjallar through an exchange server - works fine. BUT... it takes a small patch, if you are interested I can dig it out from Gjallar. regards, Göran > Hi Lukas > > I guess authenticated SMTP means sending a name and password to the ISP > via > an agreed protocol - if someone thinks it possible and worth doing I think > it would be useful. > > Do you know how to send emails through localhost in the way you suggest? > > Yours > > Bob > --- > >>How do you want to do authenticated SMTP? I guess Squeak does not >>support that by default. > >>As far as I remember, seasidehosting.st allows to send a limited >>number of mails trough localhost. This is also what the management >>application is doing (which itself is hosted on seasidehosting.st). > >>Cheers, >>Lukas > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by rhawley
> Do you know how to send emails through localhost in the way you suggest?
MailSender classPool at: #SmtpServer put: 'localhost'. SeasidePlatformSupport deliverMailFrom: '[hidden email]' to: #( '[hidden email]' '[hidden email]' ) text: 'To: [hidden email] Subject: Hallo This is a test ...' -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
That's it and note that sometimes you can observe issues with the subject
body part that I think is due to cr lf in the strings of the OS that is sending that by the socket. Cheers, Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Lukas Renggli > Enviado el: Martes, 16 de Octubre de 2007 03:56 > Para: Seaside - general discussion > Asunto: Re: [Seaside] Emailing out > > > Do you know how to send emails through localhost in the way > you suggest? > > MailSender classPool at: #SmtpServer put: 'localhost'. > SeasidePlatformSupport > deliverMailFrom: '[hidden email]' > to: #( '[hidden email]' '[hidden email]' ) > text: 'To: [hidden email] > Subject: Hallo > > This is a test ...' > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> That's it and note that sometimes you can observe issues with the subject
> body part that I think is due to cr lf in the strings of the OS that is > sending that by the socket. The SMTP client of Squeak fixes the line endings, AFAIK. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by rhawley
Hi Goran
It would be useful to be able to use authenticated SMTP - if you have the patch I would be interested in using it. Thanks >Hi guys! >Squeak supports authenticated SMTP - we use it in Gjallar through an >exchange server - works fine. BUT... it takes a small patch, if you are >interested I can dig it out from Gjallar. >regards, Göran _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by rhawley
Hi Lukas
It worked fine - thank you. Yours Bob > Do you know how to send emails through localhost in the way you suggest? MailSender classPool at: #SmtpServer put: 'localhost'. SeasidePlatformSupport deliverMailFrom: 'your at some.com' to: #( 'first at test.com' 'second at test.com' ) text: 'To: first at test.com Subject: Hallo This is a test ...' -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
This is a problem that has been posted about a few times, but until
yesterday I wasn't able to put my finger on the cause. I'm not absolutely sure why this is, but it seems that IE has some pretty draconian hard coded limits in place about how long a form submit can be. When writing programs in Run BASIC on IE once a program gets to be a few thousand bytes long the submit fails when trying to do anything on the page (running, saving, etc.). The result is the dreaded "Internet Explorer cannot display the webpage" error message. Has anyone else here had to deal with this? Is there a way to work around the problem? I'm using VW7.4.1 and Seaside 2.6 and Web Toolkit. Do newer versions of Seaside handle this differently? Thanks, -Carl Gundel http://www.runbasic.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
I've looked a little bit more into this. I don't know how reliable this
information is but I've seen it in a few places. The general concensus is that IE limits GET form submissions to about 2000 characters. No limits are placed on POST submits. I don't know a whole heck of a lot about the difference between the two (which is why I use Seaside ;-). Perhaps other browsers have similar mechanisms in place for GETs, but they are simply larger and it would just be a matter of time before the ceiling is reached on Firefox or Safari. -Carl > This is a problem that has been posted about a few times, but until > yesterday I wasn't able to put my finger on the cause. I'm not absolutely > sure why this is, but it seems that IE has some pretty draconian hard > coded limits in place about how long a form submit can be. When writing > programs in Run BASIC on IE once a program gets to be a few thousand bytes > long the submit fails when trying to do anything on the page (running, > saving, etc.). The result is the dreaded "Internet Explorer cannot display > the webpage" error message. Has anyone else here had to deal with this? > Is there a way to work around the problem? > > I'm using VW7.4.1 and Seaside 2.6 and Web Toolkit. Do newer versions of > Seaside handle this differently? > > Thanks, > > -Carl Gundel > http://www.runbasic.com > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Hello,
I'll try to make the difference between the two as clear as mud. First, GET. GET is really easy. What it means is that all of the submitted information is in the URL. http://mysite/mypage?x=1&y=2 is a simple GET submission that sends x = 1 and y = 2 to the server. There is a limit on how long URLs can be. POST is a little more complex, and I think that I'll need to delve a bit into the depths of HTTP to explain it. When you make an HTTP request -- say that GET request above -- what happens is that your browser connects to the server, sends it some information (the page you're looking for, some browser info, where you came from, etc), and then reads the response from the server (this response is the contents of the HTML page that the browser is going to show). A POST request does the same as a GET, but allows the browser to add more information (think of it as a section marked "this is where the data that you want to submit"). It's a different section then what the GET uses -- the GET includes the data in the section that indicates the page you are looking for. POST requests are allowed to be essentially unlimited. (Unlimited for practical purposes... but then again, try uploading a really huge file... uploading a file with a browser is a POST rquest). HTH, - m Saturday, November 10, 2007, 1:15:34 PM, you wrote: > I've looked a little bit more into this. I don't know how reliable this > information is but I've seen it in a few places. The general concensus is > that IE limits GET form submissions to about 2000 characters. No limits are > placed on POST submits. I don't know a whole heck of a lot about the > difference between the two (which is why I use Seaside ;-). Perhaps other > browsers have similar mechanisms in place for GETs, but they are simply > larger and it would just be a matter of time before the ceiling is reached > on Firefox or Safari. > -Carl >> This is a problem that has been posted about a few times, but until >> yesterday I wasn't able to put my finger on the cause. I'm not absolutely >> sure why this is, but it seems that IE has some pretty draconian hard >> coded limits in place about how long a form submit can be. When writing >> programs in Run BASIC on IE once a program gets to be a few thousand bytes >> long the submit fails when trying to do anything on the page (running, >> saving, etc.). The result is the dreaded "Internet Explorer cannot display >> the webpage" error message. Has anyone else here had to deal with this? >> Is there a way to work around the problem? >> >> I'm using VW7.4.1 and Seaside 2.6 and Web Toolkit. Do newer versions of >> Seaside handle this differently? >> >> Thanks, >> >> -Carl Gundel >> http://www.runbasic.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Hi Carl
Have this important distiction in mind: GETs are not supposed to change your data, just to read it. Conceptually it is called idempotence. Check http://en.wikipedia.org/wiki/HTTP So POST if you are changing something, even if it is small. Cheers Carlos On 11/10/07, Marco Qualizza <[hidden email]> wrote: > Hello, > > I'll try to make the difference between the two as clear as mud. > > First, GET. GET is really easy. What it means is that all of the > submitted information is in the URL. http://mysite/mypage?x=1&y=2 is > a simple GET submission that sends x = 1 and y = 2 to the server. > There is a limit on how long URLs can be. > > POST is a little more complex, and I think that I'll need to delve a > bit into the depths of HTTP to explain it. When you make an HTTP > request -- say that GET request above -- what happens is that your > browser connects to the server, sends it some information (the page > you're looking for, some browser info, where you came from, etc), and > then reads the response from the server (this response is the contents > of the HTML page that the browser is going to show). A POST request > does the same as a GET, but allows the browser to add more information > (think of it as a section marked "this is where the data that you want > to submit"). It's a different section then what the GET uses -- the > GET includes the data in the section that indicates the page you are > looking for. POST requests are allowed to be essentially unlimited. > (Unlimited for practical purposes... but then again, try uploading a > really huge file... uploading a file with a browser is a POST rquest). > > HTH, > - m > > Saturday, November 10, 2007, 1:15:34 PM, you wrote: > > > I've looked a little bit more into this. I don't know how reliable this > > information is but I've seen it in a few places. The general concensus is > > that IE limits GET form submissions to about 2000 characters. No limits are > > placed on POST submits. I don't know a whole heck of a lot about the > > difference between the two (which is why I use Seaside ;-). Perhaps other > > browsers have similar mechanisms in place for GETs, but they are simply > > larger and it would just be a matter of time before the ceiling is reached > > on Firefox or Safari. > > > -Carl > > > >> This is a problem that has been posted about a few times, but until > >> yesterday I wasn't able to put my finger on the cause. I'm not absolutely > >> sure why this is, but it seems that IE has some pretty draconian hard > >> coded limits in place about how long a form submit can be. When writing > >> programs in Run BASIC on IE once a program gets to be a few thousand bytes > >> long the submit fails when trying to do anything on the page (running, > >> saving, etc.). The result is the dreaded "Internet Explorer cannot display > >> the webpage" error message. Has anyone else here had to deal with this? > >> Is there a way to work around the problem? > >> > >> I'm using VW7.4.1 and Seaside 2.6 and Web Toolkit. Do newer versions of > >> Seaside handle this differently? > >> > >> Thanks, > >> > >> -Carl Gundel > >> http://www.runbasic.com > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Okay, so I'm supposed to POST? I didn't realize that is within my control,
but that Seaside is making this decision for me. -Carl ----- Original Message ----- From: "Carlos Lenz" <[hidden email]> To: "Seaside - general discussion" <[hidden email]> Sent: Saturday, November 10, 2007 3:13 PM Subject: Re: Re[2]: [Seaside] Long submit problems with IE > Hi Carl > > Have this important distiction in mind: > > GETs are not supposed to change your data, just to read it. > Conceptually it is called idempotence. > Check http://en.wikipedia.org/wiki/HTTP > > So POST if you are changing something, even if it is small. > > Cheers > > Carlos > > On 11/10/07, Marco Qualizza <[hidden email]> wrote: >> Hello, >> >> I'll try to make the difference between the two as clear as mud. >> >> First, GET. GET is really easy. What it means is that all of the >> submitted information is in the URL. http://mysite/mypage?x=1&y=2 is >> a simple GET submission that sends x = 1 and y = 2 to the server. >> There is a limit on how long URLs can be. >> >> POST is a little more complex, and I think that I'll need to delve a >> bit into the depths of HTTP to explain it. When you make an HTTP >> request -- say that GET request above -- what happens is that your >> browser connects to the server, sends it some information (the page >> you're looking for, some browser info, where you came from, etc), and >> then reads the response from the server (this response is the contents >> of the HTML page that the browser is going to show). A POST request >> does the same as a GET, but allows the browser to add more information >> (think of it as a section marked "this is where the data that you want >> to submit"). It's a different section then what the GET uses -- the >> GET includes the data in the section that indicates the page you are >> looking for. POST requests are allowed to be essentially unlimited. >> (Unlimited for practical purposes... but then again, try uploading a >> really huge file... uploading a file with a browser is a POST rquest). >> >> HTH, >> - m >> >> Saturday, November 10, 2007, 1:15:34 PM, you wrote: >> >> > I've looked a little bit more into this. I don't know how reliable >> > this >> > information is but I've seen it in a few places. The general concensus >> > is >> > that IE limits GET form submissions to about 2000 characters. No >> > limits are >> > placed on POST submits. I don't know a whole heck of a lot about the >> > difference between the two (which is why I use Seaside ;-). Perhaps >> > other >> > browsers have similar mechanisms in place for GETs, but they are simply >> > larger and it would just be a matter of time before the ceiling is >> > reached >> > on Firefox or Safari. >> >> > -Carl >> >> >> >> This is a problem that has been posted about a few times, but until >> >> yesterday I wasn't able to put my finger on the cause. I'm not >> >> absolutely >> >> sure why this is, but it seems that IE has some pretty draconian hard >> >> coded limits in place about how long a form submit can be. When >> >> writing >> >> programs in Run BASIC on IE once a program gets to be a few thousand >> >> bytes >> >> long the submit fails when trying to do anything on the page (running, >> >> saving, etc.). The result is the dreaded "Internet Explorer cannot >> >> display >> >> the webpage" error message. Has anyone else here had to deal with >> >> this? >> >> Is there a way to work around the problem? >> >> >> >> I'm using VW7.4.1 and Seaside 2.6 and Web Toolkit. Do newer versions >> >> of >> >> Seaside handle this differently? >> >> >> >> Thanks, >> >> >> >> -Carl Gundel >> >> http://www.runbasic.com >> >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> -----Original Message-----
> From: [hidden email] > [mailto:[hidden email]] On Behalf > Of Carl Gundel > Sent: Saturday, November 10, 2007 1:32 PM > To: Seaside - general discussion > Subject: Re: Re[2]: [Seaside] Long submit problems with IE > > Okay, so I'm supposed to POST? I didn't realize that is > within my control, but that Seaside is making this decision for me. > > -Carl Seaside does post forms, that's not your problem. I have seen similar symptoms caused by keep alives, try this AFTER starting up your seaside service.... HttpService allInstancesDo: [:each | each keepAlive: false]. And see if your problem goes away. Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
>> Okay, so I'm supposed to POST? I didn't realize that is
>> within my control, but that Seaside is making this decision for me. >> >> -Carl > > Seaside does post forms, that's not your problem. I have seen similar > symptoms caused by keep alives, try this AFTER starting up your seaside > service.... > > HttpService allInstancesDo: [:each | each keepAlive: false]. > > And see if your problem goes away. Thanks, but my image doesn't have any class named HttpService. I'm using VW 7.4.1, and Seaside 2.6. There are keepAlive: methods on the classes named Net.HttpClient and Net.HttpEntity. Could one of these be what you mean? -Carl _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |