Authentication task and https
Locked
Authentication task and https
 
|
Julian,
Are there any restrictions on how or on which classes to set the protocol option? So far, I have used #registerAsApplication: and then set preferences. But unless I am missing something, I can't simply browse for implementers of #serverProtocol:. Is there a way to set a protocol for something that does not deserve the label of "application" (which I read as entry point to Seaside)? As an example, suppose I have a task to get a file name, ask for some text, perhaps present a form to edit it, and then #answer: a result of the interaction; how would I go about setting its server protocol without creating an entry point? Bill ========================== Julian Fitzell jfitzell at gmail.com Fri Oct 17 11:33:16 UTC 2008 Sounds likely... the #serverXXX settings control the URLs that are generated by Seaside. If your application is running behind something like apache that makes the address different than what Seaside would expect, you should be setting those options. Julian On Thu, Oct 16, 2008 at 10:09 PM, Bill Schwab <BSchwab at anest.ufl.edu> wrote: > Hello all, > > I am working on my reference manager. One of the first things I did > was create a task for authentication, and that works as intented: give > it a user name and password it likes, and you are in; it does not allow > users to register themselves, which is the intended behavior. > > Since I switched to https, I now note that timeouts (I think) result in > an http request which Apache is configured to ignore. I probably just > need to set the #serverProtocol to 'https', but thought I should ask > first because I then have to explain why it works the first time > around. > > Any words of wisdom? > > Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 273-6785 FAX: (352) 392-7029 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Authentication task and https
|
|
No, as you surmise, it's only a preference and only used by
applications (all entry points in 2.9) and is therefore application-wide. It's basically supposed to represent the "external base url" of the application, when that is not the same as the base url of the application within the squeak image. If you're talking about wanting some part of your application to force the use of SSL then that doesn't help but I think in most cases (if you don't specify values for those parameters) it should just be generating URLs like "/seaside/foo", which will maintain the hostname, protocol, and port and should therefore keep using SSL until you manually send it to an HTTP URL. When the session expires, you'd get redirected back to the application entry point, which would be HTTP again. I think perhaps I don't quite understand what you're trying to accomplish. Maybe you could give a more concrete example with what the external and internal URLs are at various points? Julian On Fri, Oct 17, 2008 at 7:13 PM, Bill Schwab <[hidden email]> wrote: > Julian, > > Are there any restrictions on how or on which classes to set the > protocol option? So far, I have used #registerAsApplication: and then > set preferences. But unless I am missing something, I can't simply > browse for implementers of #serverProtocol:. Is there a way to set a > protocol for something that does not deserve the label of "application" > (which I read as entry point to Seaside)? As an example, suppose I have > a task to get a file name, ask for some text, perhaps present a form to > edit it, and then #answer: a result of the interaction; how would I go > about setting its server protocol without creating an entry point? > > Bill > > > > > ========================== > Julian Fitzell jfitzell at gmail.com > Fri Oct 17 11:33:16 UTC 2008 > > Sounds likely... the #serverXXX settings control the URLs that are > generated by Seaside. If your application is running behind something > like apache that makes the address different than what Seaside would > expect, you should be setting those options. > > Julian > > On Thu, Oct 16, 2008 at 10:09 PM, Bill Schwab <BSchwab at anest.ufl.edu> > wrote: >> Hello all, >> >> I am working on my reference manager. One of the first things I did >> was create a task for authentication, and that works as intented: give >> it a user name and password it likes, and you are in; it does not > allow >> users to register themselves, which is the intended behavior. >> >> Since I switched to https, I now note that timeouts (I think) result > in >> an http request which Apache is configured to ignore. I probably just >> need to set the #serverProtocol to 'https', but thought I should ask >> first because I then have to explain why it works the first time >> around. >> >> Any words of wisdom? >> >> Bill > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: [hidden email] > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > _______________________________________________ > 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 |
RE: Authentication task and https
|
|
In reply to this post by Schwab,Wilhelm K
>
> Julian, > > Are there any restrictions on how or on which classes to set the > protocol option? So far, I have used #registerAsApplication: and then > set preferences. But unless I am missing something, I can't simply > browse for implementers of #serverProtocol:. Is there a way to set a > protocol for something that does not deserve the label of > "application" > (which I read as entry point to Seaside)? As an example, > suppose I have > a task to get a file name, ask for some text, perhaps present > a form to > edit it, and then #answer: a result of the interaction; how would I go > about setting its server protocol without creating an entry point? > > Bill See http://code.google.com/p/seaside/issues/detail?id=97 I think that's what you're looking for. Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Authentication task and https
|
|
In reply to this post by Schwab,Wilhelm K
Julian,
My goal is to keep things simple and safe. Sending sensitive data in the clear is a big mistake; the less that changes between my testing and production environments, the better. Between moving to a domain certificate and the ease of self-signing in transition and on test machines, I have decided to use SSL for everything for the forseeable future. I will also default to requiring authentication, so I created a task in hope of doing the hard part once. The best I could think to do is to have an abstract task that looks something like this: go | userComponent | user := SeasideUserAuthentication new. userComponent := SeasideUserAuthenticationComponent new user:user; yourself. [ user authenticate ] whileFalse:[ self call:userComponent. user authenticate ifTrue:[ self session login:user. self call:self startingComponent. ]. ]. self session logout. where #startingComponent is defined for each subclass/application. There might be a completely pluggable solution to the problem, but it escaped me. A subclass is registered something like application := self registerAsApplication: 'hal9000'. application preferenceAt: #deploymentMode put: true. application preferenceAt: #resourceBaseUrl put: '/'. application preferenceAt: #serverPath put: '/'. application preferenceAt: #serverPort put: 443. application preferenceAt: #serverProtocol put: #https. Apache is configured to not even listen on 80, and I am happy to require a user to start with a URL such as https://here.there.net/seaside/hal9000 Life starts out with https, but with inactivity, (I assume) on session timeout, the browser gets bounced back to http://here.there.net/seaside/hal9000 If only rhetorically, why does it work on the first pass? I am not sure what you mean by internal and external URLs. So far, searches turn up hits, but not anything that tells me how to grab them. Are you referring to outside and inside Comanche, or on either side of Apache? Thanks! Bill ============================= From: Julian Fitzell <jfitzell <at> gmail.com> Subject: Re: Authentication task and https Newsgroups: gmane.comp.lang.smalltalk.squeak.seaside Date: 2008-10-17 18:17:20 GMT No, as you surmise, it's only a preference and only used by applications (all entry points in 2.9) and is therefore application-wide. It's basically supposed to represent the "external base url" of the application, when that is not the same as the base url of the application within the squeak image. If you're talking about wanting some part of your application to force the use of SSL then that doesn't help but I think in most cases (if you don't specify values for those parameters) it should just be generating URLs like "/seaside/foo", which will maintain the hostname, protocol, and port and should therefore keep using SSL until you manually send it to an HTTP URL. When the session expires, you'd get redirected back to the application entry point, which would be HTTP again. I think perhaps I don't quite understand what you're trying to accomplish. Maybe you could give a more concrete example with what the external and internal URLs are at various points? Julian Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 273-6785 FAX: (352) 392-7029 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Authentication task and https
|
|
In reply to this post by Schwab,Wilhelm K
Ramon,
It will probably solve my problem. I do in fact want to enforce a global setting (sending clear text is BAAAAADDDD for most of what I do), so I am expecting to make everything secured and needing authentication, at least for a while. Later on, having a way to reliably mix them will be greatly appreciated. For now, my problem is perhaps simply that the authentication task is not registered, and as such did not get a protocol set. That much more or less makes sense to me (intuitively at least - I am still struggling to grok Seaside's entrails). What I do not understand is why the initial authentication challenge arrives via https (which is what I want). Since I did nothing other than set https for the application, I would naively expect the same juju that encrypted the first authentication to encrypt the subsequent ones. For my education, can you explain what might be happening? Either way, setting the protocol "too often" is probably fine for my purposes. Thanks! Bill ======================= Ramon Leon See http://code.google.com/p/seaside/issues/detail?id=97 I think that's what you're looking for. Ramon Leon http://onsmalltalk.com Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 273-6785 FAX: (352) 392-7029 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Re: Authentication task and https
|
|
In reply to this post by Schwab,Wilhelm K
Hi Bill,
I took a quick look at the code. I'm pretty sure the problem is likely to be in WARegistry>>handleExpiredRequest: because it isn't using #baseUrl anywhere while generating the code. It's trying to take the everything from the incoming request URL but that might not work, particularly if you're behind Apache. This code is a mess... it's cleaned up quite a bit in 2.9 but still has calls to #takeServerParametersFromRequest: which I'm a little unsure of. So... I would try either overriding that method on WAApplication or modifying it directly. I would start by using "self baseUrl" instead of "WAUrl new" but you might then have to strip off the path or something because the whole path from the incoming request then gets added. I'm also not even sure if *that* part makes sense when the request is being rewritten. It seems like you'd really need to keep the path from #baseUrl (which takes into account the config settings), subtract #basePath (the actual path on the squeak image) from the path in the incoming request, and then apply what's left of the incoming request's path to the redirection. I hope that makes any kind of sense. It's muddling my head just thinking about it so if it doesn't, I can try to explain again. Hopefully you can sort it out with only a little bit of muddling and let us know the answer... we should probably try to roll some kind of a fix out for that at some point. And yes, by "internal" and "external" I meant "the URL of the squeak image" and the "URL visible outside Apache". Julian On Sat, Oct 18, 2008 at 12:38 AM, Bill Schwab <[hidden email]> wrote: > Julian, > > My goal is to keep things simple and safe. Sending sensitive data in > the clear is a big mistake; the less that changes between my testing and > production environments, the better. Between moving to a domain > certificate and the ease of self-signing in transition and on test > machines, I have decided to use SSL for everything for the forseeable > future. I will also default to requiring authentication, so I created a > task in hope of doing the hard part once. The best I could think to do > is to have an abstract task that looks something like this: > > go > | userComponent | > user := SeasideUserAuthentication new. > userComponent := SeasideUserAuthenticationComponent new > user:user; yourself. > > [ user authenticate ] whileFalse:[ > self call:userComponent. > user authenticate > ifTrue:[ > self session login:user. > self call:self startingComponent. > ]. > ]. > > self session logout. > > where #startingComponent is defined for each subclass/application. > There might be a completely pluggable solution to the problem, but it > escaped me. > > A subclass is registered something like > > application := self registerAsApplication: 'hal9000'. > application preferenceAt: #deploymentMode put: true. > application preferenceAt: #resourceBaseUrl put: '/'. > application preferenceAt: #serverPath put: '/'. > application preferenceAt: #serverPort put: 443. > application preferenceAt: #serverProtocol put: #https. > > Apache is configured to not even listen on 80, and I am happy to > require a user to start with a URL such as > > https://here.there.net/seaside/hal9000 > > > Life starts out with https, but with inactivity, (I assume) on session > timeout, the browser gets bounced back to > > http://here.there.net/seaside/hal9000 > > > If only rhetorically, why does it work on the first pass? I am not > sure what you mean by internal and external URLs. So far, searches turn > up hits, but not anything that tells me how to grab them. Are you > referring to outside and inside Comanche, or on either side of Apache? > > Thanks! > > Bill > > > > > > ============================= > From: Julian Fitzell <jfitzell <at> gmail.com> > Subject: Re: Authentication task and https > Newsgroups: gmane.comp.lang.smalltalk.squeak.seaside > Date: 2008-10-17 18:17:20 GMT > > No, as you surmise, it's only a preference and only used by > applications (all entry points in 2.9) and is therefore > application-wide. It's basically supposed to represent the "external > base url" of the application, when that is not the same as the base > url of the application within the squeak image. > > If you're talking about wanting some part of your application to force > the use of SSL then that doesn't help but I think in most cases (if > you don't specify values for those parameters) it should just be > generating URLs like "/seaside/foo", which will maintain the hostname, > protocol, and port and should therefore keep using SSL until you > manually send it to an HTTP URL. When the session expires, you'd get > redirected back to the application entry point, which would be HTTP > again. > > I think perhaps I don't quite understand what you're trying to > accomplish. Maybe you could give a more concrete example with what the > external and internal URLs are at various points? > > Julian > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: [hidden email] > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > _______________________________________________ > 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 |
Re: Authentication task and https
|
|
In reply to this post by Schwab,Wilhelm K
Julian Fitzell
Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Julian, What scares me is that it does make some sense :) Not that I really understand it, but from "the" book (too lazy to look up the title), some of it sounds familiar. It sure makes more sense than the proxy/location directives that mention only the one protocol and yet somehow seem to rewrite the URLs. I will be happy to help sort it out. The first thing that comes to mind is that despite many different sources stating how easy it is to proxy Seaside with Apache, it is in fact not all that easy. Given the nature of Apache, I doubt it can ever be made trivial, but we should be able to make it less daunting. I have the beginnings of something that can sniff around for Seaside apps and propose parts of configuration files. I have avoided rewrites on advice from Pinesoft, but we could "easily" support either approach. Bill ============================== Julian Fitzell jfitzell at gmail.com Thu Oct 23 07:07:05 UTC 2008 Hi Bill, I took a quick look at the code. I'm pretty sure the problem is likely to be in WARegistry>>handleExpiredRequest: because it isn't using #baseUrl anywhere while generating the code. It's trying to take the everything from the incoming request URL but that might not work, particularly if you're behind Apache. This code is a mess... it's cleaned up quite a bit in 2.9 but still has calls to #takeServerParametersFromRequest: which I'm a little unsure of. So... I would try either overriding that method on WAApplication or modifying it directly. I would start by using "self baseUrl" instead of "WAUrl new" but you might then have to strip off the path or something because the whole path from the incoming request then gets added. I'm also not even sure if *that* part makes sense when the request is being rewritten. It seems like you'd really need to keep the path from #baseUrl (which takes into account the config settings), subtract #basePath (the actual path on the squeak image) from the path in the incoming request, and then apply what's left of the incoming request's path to the redirection. I hope that makes any kind of sense. It's muddling my head just thinking about it so if it doesn't, I can try to explain again. Hopefully you can sort it out with only a little bit of muddling and let us know the answer... we should probably try to roll some kind of a fix out for that at some point. And yes, by "internal" and "external" I meant "the URL of the squeak image" and the "URL visible outside Apache". Julian Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 273-6785 FAX: (352) 392-7029 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Re: Authentication task and https
|
|
On Thu, Oct 23, 2008 at 4:50 PM, Bill Schwab <[hidden email]> wrote:
> Julian, > > What scares me is that it does make some sense :) Not that I really > understand it, but from "the" book (too lazy to look up the title), some > of it sounds familiar. It sure makes more sense than the proxy/location > directives that mention only the one protocol and yet somehow seem to > rewrite the URLs. :) > I will be happy to help sort it out. The first thing that comes to mind > is that despite many different sources stating how easy it is to proxy > Seaside with Apache, it is in fact not all that easy. Given the nature > of Apache, I doubt it can ever be made trivial, but we should be able to > make it less daunting. I have the beginnings of something that can > sniff around for Seaside apps and propose parts of configuration files. > I have avoided rewrites on advice from Pinesoft, but we could "easily" > support either approach. Agreed. We need to make that better. Partly, the UI needs to make more sense and partly it needs some documentation. I really isn't that hard if you understand the pieces involved but we're doing a very poor job of getting people to that pre-requisite currently and it all ends up being a bit opaque. Improving the user experience in areas such as these is a goal of mine for the later alpha or beta releases of 2.9 and I've also been assigned the task of writing some architectural documentation following the cleanups we've done (which includes touching some of this baseUrl stuff) so I'll try to make sure it addresses this to some degree. Julian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |