TLS support & Encrypted cookies

[sheganinans]

TLS support, now with quadruply encrypted cookies!

[agocorona]

Aistis,

I added the first patch. Can you verify if you have the same problem? When trying to run demos-blaze.hs, it report "atomically nested". And when I try to run LoginSample.hs alone using runSecureNavigation it produces

LoginSample.hs: getAddrInfo: does not exist (error 10093)

Can you test if you have the same problem? . Maybe is my own configuration, version of libraries etc. I still have to master how to rollback using git, to test it without the patch applied.....

2014/1/1 Aistis Raulinaitis notifications@github.com

TLS support, now with quadruply encrypted cookies!

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31420881 .

Alberto.

[sheganinans]

If I try:

*MFlow> :l Demos/demos-blaze.hs ghc: could not execute: MonadLoc

Otherwise everything else works fine for me. Both LoginSample.hs and EncryptedSample.hs work well.

MFlow> :l Demos/LoginSample.hs [ 1 of 13] Compiling MFlow.Cookies ( src/MFlow/Cookies.hs, interpreted ) [ 2 of 13] Compiling MFlow ( src/MFlow.hs, interpreted ) [ 3 of 13] Compiling MFlow.Forms.Internals ( src/MFlow/Forms/Internals.hs, interpreted ) [ 4 of 13] Compiling MFlow.Forms ( src/MFlow/Forms.hs, interpreted ) [ 5 of 13] Compiling MFlow.Forms.Blaze.Html ( src/MFlow/Forms/Blaze/Html.hs, interpreted ) [ 6 of 13] Compiling MFlow.Forms.XHtml ( src/MFlow/Forms/XHtml.hs, interpreted ) [ 7 of 13] Compiling MFlow.Forms.Admin ( src/MFlow/Forms/Admin.hs, interpreted ) [ 8 of 13] Compiling MFlow.Forms.Widgets ( src/MFlow/Forms/Widgets.hs, interpreted ) [ 9 of 13] Compiling MFlow.Wai.Response ( src/MFlow/Wai/Response.hs, interpreted ) [10 of 13] Compiling MFlow.Wai ( src/MFlow/Wai.hs, interpreted ) [11 of 13] Compiling MFlow.Wai.Blaze.Html.All ( src/MFlow/Wai/Blaze/Html/All.hs, interpreted ) [12 of 13] Compiling Menu ( Menu.hs, interpreted ) [13 of 13] Compiling LoginSample ( Demos/LoginSample.hs, interpreted ) Ok, modules loaded: MFlow, MFlow.Cookies, MFlow.Wai.Blaze.Html.All, MFlow.Forms, MFlow.Forms.Widgets, MFlow.Forms.Blaze.Html, MFlow.Forms.Admin, MFlow.Wai, MFlow.Forms.XHtml, MFlow.Forms.Internals, MFlow.Wai.Response, LoginSample, Menu. LoginSample> runNavigation "" . step $ do loginSample using port 8080 Ruwnaniitn:g riena dy2 core(s)

MFlow> :l Demos/EncryptedLoginSample.hs [ 1 of 13] Compiling MFlow.Cookies ( src/MFlow/Cookies.hs, interpreted ) [ 2 of 13] Compiling MFlow ( src/MFlow.hs, interpreted ) [ 3 of 13] Compiling MFlow.Forms.Internals ( src/MFlow/Forms/Internals.hs, interpreted ) [ 4 of 13] Compiling MFlow.Forms ( src/MFlow/Forms.hs, interpreted ) [ 5 of 13] Compiling MFlow.Forms.Blaze.Html ( src/MFlow/Forms/Blaze/Html.hs, interpreted ) [ 6 of 13] Compiling MFlow.Forms.XHtml ( src/MFlow/Forms/XHtml.hs, interpreted ) [ 7 of 13] Compiling MFlow.Forms.Admin ( src/MFlow/Forms/Admin.hs, interpreted ) [ 8 of 13] Compiling MFlow.Forms.Widgets ( src/MFlow/Forms/Widgets.hs, interpreted ) [ 9 of 13] Compiling MFlow.Wai.Response ( src/MFlow/Wai/Response.hs, interpreted ) [10 of 13] Compiling MFlow.Wai ( src/MFlow/Wai.hs, interpreted ) [11 of 13] Compiling MFlow.Wai.Blaze.Html.All ( src/MFlow/Wai/Blaze/Html/All.hs, interpreted ) [12 of 13] Compiling Menu ( Menu.hs, interpreted ) [13 of 13] Compiling LoginSample ( Demos/LoginSample.hs, interpreted ) Ok, modules loaded: MFlow, MFlow.Cookies, MFlow.Wai.Blaze.Html.All, MFlow.Forms, MFlow.Forms.Widgets, MFlow.Forms.Blaze.Html, MFlow.Forms.Admin, MFlow.Wai, MFlow.Forms.XHtml, MFlow.Forms.Internals, MFlow.Wai.Response, LoginSample, Menu. LoginSample> runNavigation "" . step $ do paranoidLoginSample using port 8080 Ruwnaniitn:g riena dy2 core(s)

[sheganinans]

I just tried both:

In Demo/LoginSample.hs:

runSecureNavigation "" . step $ do loginSample

And Demo/EncryptedLoginSample:

runSecureNavigation "" . step $ do paranoidLoginSample

Both work on my end.

[agocorona]

Don´t worry.

I have to investigate what happens. I had some uncommitted changes that you may not have and these may be the cause of the errors. The problem is that I did the update over these change and i pushed them to github. So i´m afraid that the erroneous code is now in github. Or, else, if it is a problem of my libraries. I have to check it.

2014/1/1 Aistis Raulinaitis notifications@github.com

Sorry for all the commit spam! There were a couple of loose ends I forgot. :)

On Wed, Jan 1, 2014 at 3:09 AM, agocorona notifications@github.com wrote:

Aistis,

I added the first patch. Can you verify if you have the same problem? When trying to run demos-blaze.hs, it report "atomically nested". And when I try to run LoginSample.hs alone using runSecureNavigation it produces

LoginSample.hs: getAddrInfo: does not exist (error 10093)

Can you test if you have the same problem? . Maybe is my own configuration, version of libraries etc. I still have to master how to rollback using git, to test it without the patch applied.....

2014/1/1 Aistis Raulinaitis notifications@github.com

TLS support, now with quadruply encrypted cookies!

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31420881> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421433> .

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31421685 .

Alberto.

[sheganinans]

No worries, you can always just clone my branch to test my changes away from your branch.

On Wed, Jan 1, 2014 at 3:53 AM, agocorona notifications@github.com wrote:

Don´t worry.

I have to investigate what happens. I had some uncommitted changes that you may not have and these may be the cause of the errors. The problem is that I did the update over these change and i pushed them to github. So i´m afraid that the erroneous code is now in github. Or, else, if it is a problem of my libraries. I have to check it.

2014/1/1 Aistis Raulinaitis notifications@github.com

Sorry for all the commit spam! There were a couple of loose ends I forgot. :)

On Wed, Jan 1, 2014 at 3:09 AM, agocorona notifications@github.com wrote:

Aistis,

I added the first patch. Can you verify if you have the same problem? When trying to run demos-blaze.hs, it report "atomically nested". And when I try to run LoginSample.hs alone using runSecureNavigation it produces

LoginSample.hs: getAddrInfo: does not exist (error 10093)

Can you test if you have the same problem? . Maybe is my own configuration, version of libraries etc. I still have to master how to rollback using git, to test it without the patch applied.....

2014/1/1 Aistis Raulinaitis notifications@github.com

TLS support, now with quadruply encrypted cookies!

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31420881> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421433> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421685> .

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31421892 .

[sheganinans]

git clone https://github.com/sheganinans/MFlow.git mflow-a

That will name the file differently to avoid the name clash. But I'm sure you know all of this already!

On Wed, Jan 1, 2014 at 3:59 AM, Aistis Raulinaitis sheganinans@gmail.comwrote:

No worries, you can always just clone my branch to test my changes away from your branch.

On Wed, Jan 1, 2014 at 3:53 AM, agocorona notifications@github.comwrote:

Don´t worry.

I have to investigate what happens. I had some uncommitted changes that you may not have and these may be the cause of the errors. The problem is that I did the update over these change and i pushed them to github. So i´m afraid that the erroneous code is now in github. Or, else, if it is a problem of my libraries. I have to check it.

2014/1/1 Aistis Raulinaitis notifications@github.com

Sorry for all the commit spam! There were a couple of loose ends I forgot. :)

On Wed, Jan 1, 2014 at 3:09 AM, agocorona notifications@github.com wrote:

Aistis,

I added the first patch. Can you verify if you have the same problem? When trying to run demos-blaze.hs, it report "atomically nested". And when I try to run LoginSample.hs alone using runSecureNavigation it produces

LoginSample.hs: getAddrInfo: does not exist (error 10093)

Can you test if you have the same problem? . Maybe is my own configuration, version of libraries etc. I still have to master how to rollback using git, to test it without the patch applied.....

2014/1/1 Aistis Raulinaitis notifications@github.com

TLS support, now with quadruply encrypted cookies!

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31420881> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421433> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421685> .

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31421892 .

[agocorona]

I tested your code and works well. Wow. You are very good as a programmer. I still do not find what makes my code fail. I probably will push your version after some test.

instead of three setCookie varieties I'm thinking on a encription flag in MFlowState with three values: NoEncription, Encription and Paranoid, so that we can use the same setCookie call and thus the same userWidget , userLogin and so on in the three modes instead of multiplying the user related calls. At the same time the application programmer can also change the encription of their cookies simply changing the flag.

I ever try to limit the API surface, and make it as organic as possible, that means less calls and more modifiers that perform different but related things with the same call, because it makes it simpler to learn and more composable. That is a good design principle.

I do not know when the cookie is decripted. for example there is a getCurrentUser. I have to use it to check if has a certain value in order to give permissions to edit a template, for example. Or for checking if it is the Administrator user. Currently this user name comes from the cookie. How I know either if I have to decript the user cookie or not?: By having a flag for cookie encription, we can solve it.

2014/1/1 Aistis Raulinaitis notifications@github.com

git clone https://github.com/sheganinans/MFlow.git mflow-a

That will name the file differently to avoid the name clash. But I'm sure you know all of this already!

On Wed, Jan 1, 2014 at 3:59 AM, Aistis Raulinaitis sheganinans@gmail.comwrote:

No worries, you can always just clone my branch to test my changes away from your branch.

On Wed, Jan 1, 2014 at 3:53 AM, agocorona notifications@github.comwrote:

Don´t worry.

I have to investigate what happens. I had some uncommitted changes that you may not have and these may be the cause of the errors. The problem is that I did the update over these change and i pushed them to github. So i´m afraid that the erroneous code is now in github. Or, else, if it is a problem of my libraries. I have to check it.

2014/1/1 Aistis Raulinaitis notifications@github.com

Sorry for all the commit spam! There were a couple of loose ends I forgot. :)

On Wed, Jan 1, 2014 at 3:09 AM, agocorona notifications@github.com wrote:

Aistis,

I added the first patch. Can you verify if you have the same problem? When trying to run demos-blaze.hs, it report "atomically nested". And when I try to run LoginSample.hs alone using runSecureNavigation it produces

LoginSample.hs: getAddrInfo: does not exist (error 10093)

Can you test if you have the same problem? . Maybe is my own configuration, version of libraries etc. I still have to master how to rollback using git, to test it without the patch applied.....

2014/1/1 Aistis Raulinaitis notifications@github.com

TLS support, now with quadruply encrypted cookies!

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31420881> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421433> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421685> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421892> .

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31422024 .

Alberto.

[agocorona]

Ok, the nested atomic error was due to new configuration code in MFlow that you apparently do not have included in your repo.

The other error getAddrInfo: does not exist (error 10093) and exit.

Is produced in your code and mine with ghci . It may be due to a different library versions in the TLS libraries?

2014/1/1 Alberto G. Corona agocorona@gmail.com

I tested your code and works well. Wow. You are very good as a programmer. I still do not find what makes my code fail. I probably will push your version after some test.

instead of three setCookie varieties I'm thinking on a encription flag in MFlowState with three values: NoEncription, Encription and Paranoid, so that we can use the same setCookie call and thus the same userWidget , userLogin and so on in the three modes instead of multiplying the user related calls. At the same time the application programmer can also change the encription of their cookies simply changing the flag.

I ever try to limit the API surface, and make it as organic as possible, that means less calls and more modifiers that perform different but related things with the same call, because it makes it simpler to learn and more composable. That is a good design principle.

I do not know when the cookie is decripted. for example there is a getCurrentUser. I have to use it to check if has a certain value in order to give permissions to edit a template, for example. Or for checking if it is the Administrator user. Currently this user name comes from the cookie. How I know either if I have to decript the user cookie or not?: By having a flag for cookie encription, we can solve it.

2014/1/1 Aistis Raulinaitis notifications@github.com

git clone https://github.com/sheganinans/MFlow.git mflow-a

That will name the file differently to avoid the name clash. But I'm sure you know all of this already!

On Wed, Jan 1, 2014 at 3:59 AM, Aistis Raulinaitis sheganinans@gmail.comwrote:

No worries, you can always just clone my branch to test my changes away from your branch.

On Wed, Jan 1, 2014 at 3:53 AM, agocorona notifications@github.comwrote:

Don´t worry.

I have to investigate what happens. I had some uncommitted changes that you may not have and these may be the cause of the errors. The problem is that I did the update over these change and i pushed them to github. So i´m afraid that the erroneous code is now in github. Or, else, if it is a problem of my libraries. I have to check it.

2014/1/1 Aistis Raulinaitis notifications@github.com

Sorry for all the commit spam! There were a couple of loose ends I forgot. :)

On Wed, Jan 1, 2014 at 3:09 AM, agocorona notifications@github.com

wrote:

Aistis,

I added the first patch. Can you verify if you have the same problem? When trying to run demos-blaze.hs, it report "atomically nested". And when I try to run LoginSample.hs alone using runSecureNavigation it produces

LoginSample.hs: getAddrInfo: does not exist (error 10093)

Can you test if you have the same problem? . Maybe is my own configuration, version of libraries etc. I still have to master how to rollback using git, to test it without the patch applied.....

2014/1/1 Aistis Raulinaitis notifications@github.com

TLS support, now with quadruply encrypted cookies!

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31420881> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421433> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421685> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421892> .

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31422024 .

Alberto.

Alberto.

[agocorona]

It is an issue with warpTLS when running in Windows (I use windows):

it does not use withSocketsDo

http://stackoverflow.com/questions/19159686/internalioexception-getaddrinfo-does-not-exist-error-10093-on-windows-8

Which was fixed three days ago in the last version. I installed that version and it goes fine at last!

However since I don´t have the certificate files, it produces an error, but that was expected.

2014/1/1 Alberto G. Corona agocorona@gmail.com

Ok, the nested atomic error was due to new configuration code in MFlow that you apparently do not have included in your repo.

The other error getAddrInfo: does not exist (error 10093) and exit.

Is produced in your code and mine with ghci . It may be due to a different library versions in the TLS libraries?

2014/1/1 Alberto G. Corona agocorona@gmail.com

I tested your code and works well. Wow. You are very good as a

programmer. I still do not find what makes my code fail. I probably will push your version after some test.

instead of three setCookie varieties I'm thinking on a encription flag in MFlowState with three values: NoEncription, Encription and Paranoid, so that we can use the same setCookie call and thus the same userWidget , userLogin and so on in the three modes instead of multiplying the user related calls. At the same time the application programmer can also change the encription of their cookies simply changing the flag.

I ever try to limit the API surface, and make it as organic as possible, that means less calls and more modifiers that perform different but related things with the same call, because it makes it simpler to learn and more composable. That is a good design principle.

I do not know when the cookie is decripted. for example there is a getCurrentUser. I have to use it to check if has a certain value in order to give permissions to edit a template, for example. Or for checking if it is the Administrator user. Currently this user name comes from the cookie. How I know either if I have to decript the user cookie or not?: By having a flag for cookie encription, we can solve it.

2014/1/1 Aistis Raulinaitis notifications@github.com

git clone https://github.com/sheganinans/MFlow.git mflow-a

That will name the file differently to avoid the name clash. But I'm sure you know all of this already!

On Wed, Jan 1, 2014 at 3:59 AM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

No worries, you can always just clone my branch to test my changes away from your branch.

On Wed, Jan 1, 2014 at 3:53 AM, agocorona notifications@github.comwrote:

Don´t worry.

I have to investigate what happens. I had some uncommitted changes that you may not have and these may be the cause of the errors. The problem is that I did the update over these change and i pushed them to github. So i´m afraid that the erroneous code is now in github. Or, else, if it is a problem of my libraries. I have to check it.

2014/1/1 Aistis Raulinaitis notifications@github.com

Sorry for all the commit spam! There were a couple of loose ends I forgot. :)

On Wed, Jan 1, 2014 at 3:09 AM, agocorona notifications@github.com

wrote:

Aistis,

I added the first patch. Can you verify if you have the same problem? When trying to run demos-blaze.hs, it report "atomically nested". And when I try to run LoginSample.hs alone using runSecureNavigation it produces

LoginSample.hs: getAddrInfo: does not exist (error 10093)

Can you test if you have the same problem? . Maybe is my own configuration, version of libraries etc. I still have to master how to rollback using git, to test it without the patch applied.....

2014/1/1 Aistis Raulinaitis notifications@github.com

TLS support, now with quadruply encrypted cookies!

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31420881>

.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421433> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421685> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421892> .

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31422024 .

Alberto.

Alberto.

Alberto.

[sheganinans]

Ah, yes I haven't done any testing with Windows yet. Although since I'm not doing much filesystem magic it should work fine. Glad to hear you got that problem sorted out! I just sent a pull request to Mr. Snoyberg's clientsession library to pull out the "newKey" function, which was hidden away in a where clause. When he accepts it, it should be very easy to generate your own keys. Otherwise I can send you the keys I generated.

On Wed, Jan 1, 2014 at 3:00 PM, agocorona notifications@github.com wrote:

It is an issue with warpTLS when running in Windows (I use windows):

it does not use withSocketsDo

http://stackoverflow.com/questions/19159686/internalioexception-getaddrinfo-does-not-exist-error-10093-on-windows-8

Which was fixed three days ago in the last version. I installed that version and it goes fine at last!

However since I don´t have the certificate files, it produces an error, but that was expected.

2014/1/1 Alberto G. Corona agocorona@gmail.com

Ok, the nested atomic error was due to new configuration code in MFlow that you apparently do not have included in your repo.

The other error getAddrInfo: does not exist (error 10093) and exit.

Is produced in your code and mine with ghci . It may be due to a different library versions in the TLS libraries?

2014/1/1 Alberto G. Corona agocorona@gmail.com

I tested your code and works well. Wow. You are very good as a

programmer. I still do not find what makes my code fail. I probably will push your version after some test.

instead of three setCookie varieties I'm thinking on a encription flag in MFlowState with three values: NoEncription, Encription and Paranoid, so that we can use the same setCookie call and thus the same userWidget , userLogin and so on in the three modes instead of multiplying the user related calls. At the same time the application programmer can also change the encription of their cookies simply changing the flag.

I ever try to limit the API surface, and make it as organic as possible, that means less calls and more modifiers that perform different but related things with the same call, because it makes it simpler to learn and more composable. That is a good design principle.

I do not know when the cookie is decripted. for example there is a getCurrentUser. I have to use it to check if has a certain value in order to give permissions to edit a template, for example. Or for checking if it is the Administrator user. Currently this user name comes from the cookie. How I know either if I have to decript the user cookie or not?: By having a flag for cookie encription, we can solve it.

2014/1/1 Aistis Raulinaitis notifications@github.com

git clone https://github.com/sheganinans/MFlow.git mflow-a

That will name the file differently to avoid the name clash. But I'm sure you know all of this already!

On Wed, Jan 1, 2014 at 3:59 AM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

No worries, you can always just clone my branch to test my changes away from your branch.

On Wed, Jan 1, 2014 at 3:53 AM, agocorona notifications@github.comwrote:

Don´t worry.

I have to investigate what happens. I had some uncommitted changes that you may not have and these may be the cause of the errors. The problem is that I did the update over these change and i pushed them to github. So i´m afraid that the erroneous code is now in github. Or, else, if it is a problem of my libraries. I have to check it.

2014/1/1 Aistis Raulinaitis notifications@github.com

Sorry for all the commit spam! There were a couple of loose ends I forgot. :)

On Wed, Jan 1, 2014 at 3:09 AM, agocorona < notifications@github.com>

wrote:

Aistis,

I added the first patch. Can you verify if you have the same problem? When trying to run demos-blaze.hs, it report "atomically nested". And when I try to run LoginSample.hs alone using runSecureNavigation it produces

LoginSample.hs: getAddrInfo: does not exist (error 10093)

Can you test if you have the same problem? . Maybe is my own configuration, version of libraries etc. I still have to master how to rollback using git, to test it without the patch applied.....

2014/1/1 Aistis Raulinaitis notifications@github.com

TLS support, now with quadruply encrypted cookies!

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31420881>

.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421433>

.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421685> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421892> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31422024> .

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31432262 .

[sheganinans]

So I noticed that the execution trace shows the cookies in their encrypted state. Obviously we don't want that. I was thinking of creating another instance of MonadLoc, but then I realized that I wouldn't really be able to do it nicely without a new encrypted FlowM class. I would want to do it this way, instead of having some case statement or pattern match somewhere. What do you think? I think this will also make it easier to reason about what is encrypted and what is unencrypted. I was also thinking of making an encrypted cookie class as well, to make sure that all of this encryption separation is handled at the type level. Are there any other classes that would do well with an encrypted counterpart?

Also, for separation of concerns, have you seen this package? http://hackage.haskell.org/package/seclib

On Thu, Jan 2, 2014 at 12:31 AM, Aistis Raulinaitis sheganinans@gmail.comwrote:

Ah, yes I haven't done any testing with Windows yet. Although since I'm not doing much filesystem magic it should work fine. Glad to hear you got that problem sorted out! I just sent a pull request to Mr. Snoyberg's clientsession library to pull out the "newKey" function, which was hidden away in a where clause. When he accepts it, it should be very easy to generate your own keys. Otherwise I can send you the keys I generated.

On Wed, Jan 1, 2014 at 3:00 PM, agocorona notifications@github.comwrote:

It is an issue with warpTLS when running in Windows (I use windows):

it does not use withSocketsDo

http://stackoverflow.com/questions/19159686/internalioexception-getaddrinfo-does-not-exist-error-10093-on-windows-8

Which was fixed three days ago in the last version. I installed that version and it goes fine at last!

However since I don´t have the certificate files, it produces an error, but that was expected.

2014/1/1 Alberto G. Corona agocorona@gmail.com

Ok, the nested atomic error was due to new configuration code in MFlow that you apparently do not have included in your repo.

The other error getAddrInfo: does not exist (error 10093) and exit.

Is produced in your code and mine with ghci . It may be due to a different library versions in the TLS libraries?

2014/1/1 Alberto G. Corona agocorona@gmail.com

I tested your code and works well. Wow. You are very good as a

programmer. I still do not find what makes my code fail. I probably will push your version after some test.

instead of three setCookie varieties I'm thinking on a encription flag in MFlowState with three values: NoEncription, Encription and Paranoid, so that we can use the same setCookie call and thus the same userWidget , userLogin and so on in the three modes instead of multiplying the user related calls. At the same time the application programmer can also change the encription of their cookies simply changing the flag.

I ever try to limit the API surface, and make it as organic as possible, that means less calls and more modifiers that perform different but related things with the same call, because it makes it simpler to learn and more composable. That is a good design principle.

I do not know when the cookie is decripted. for example there is a getCurrentUser. I have to use it to check if has a certain value in order to give permissions to edit a template, for example. Or for checking if it is the Administrator user. Currently this user name comes from the cookie. How I know either if I have to decript the user cookie or not?: By having a flag for cookie encription, we can solve it.

2014/1/1 Aistis Raulinaitis notifications@github.com

git clone https://github.com/sheganinans/MFlow.git mflow-a

That will name the file differently to avoid the name clash. But I'm sure you know all of this already!

On Wed, Jan 1, 2014 at 3:59 AM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

No worries, you can always just clone my branch to test my changes away from your branch.

On Wed, Jan 1, 2014 at 3:53 AM, agocorona notifications@github.comwrote:

Don´t worry.

I have to investigate what happens. I had some uncommitted changes that you may not have and these may be the cause of the errors. The problem is that I did the update over these change and i pushed them to github. So i´m afraid that the erroneous code is now in github. Or, else, if it is a problem of my libraries. I have to check it.

2014/1/1 Aistis Raulinaitis notifications@github.com

Sorry for all the commit spam! There were a couple of loose ends I forgot. :)

On Wed, Jan 1, 2014 at 3:09 AM, agocorona < notifications@github.com>

wrote:

Aistis,

I added the first patch. Can you verify if you have the same problem? When trying to run demos-blaze.hs, it report "atomically nested". And when I try to run LoginSample.hs alone using runSecureNavigation it produces

LoginSample.hs: getAddrInfo: does not exist (error 10093)

Can you test if you have the same problem? . Maybe is my own configuration, version of libraries etc. I still have to master how to rollback using git, to test it without the patch applied.....

2014/1/1 Aistis Raulinaitis notifications@github.com

TLS support, now with quadruply encrypted cookies!

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31420881>

.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421433>

.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421685> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31421892> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31422024> .

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31432262 .

[sheganinans]

I think that creating a encrypted FlowM would also help in simplifying the implementation of the secure modifier. It would simply be a function from FlowM -> EFlowM. Just a suggestion, I'm not sure if that is the direction you want to go.

[agocorona]

I aistis.

I confess that I have no expertise on security. It is hard to take a design decission with this limitation. I took a look at the article that you linked and I have no clue of how it works. To be syncere I really hate to think about security problems. That's why when you appeared I though that my prayers had been answered ;)

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

What the EFLowM monad will do?. I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best. Can we change the mode within the session with as little syntactic overhead as possible?. You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

2014/1/2 Aistis Raulinaitis notifications@github.com

I think that creating a encrypted FlowM would also help in simplifying the implementation of the secure modifier. It would simply be a function from FlowM -> EFlowM. Just a suggestion, I'm not sure if that is the direction you want to go.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31458104 .

Alberto.

[sheganinans]

I confess that I have no expertise on security. It is hard to take a design decission with this limitation.

Good, I have quite a bit of experience with security. So that means you can focus on doing the high-level things you have been doing already!

I took a look at the article that you linked and I have no clue of how it works.

No worries, it's pretty simple. Although I don't think I would use it for MFlow. It was just an example of a good separation of "classified" and "declassified" information. It allows for the type system to enforce the safety of the information at compile time. Not exactly related to what we are doing hear!

To be syncere I really hate to think about security problems.

Well, I guess I'll continue on being the janitor/security guard! :D

That's why when you appeared I though that my prayers had been answered ;)

Good because I would tell you the exact same thing! I was blown away by seaside, nagare, and others. I wanted to see a similar web framework in Haskell, otherwise I would have had to write it myself! Not only that, but MFlow is in many ways better than what I had in mind! So it's a big win for me since you already did the work, and I want to use MFlow for real world applications.

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

Alright! I hope you like what I come up with!

What the EFLowM monad will do?.

Exactly what the regular FlowM monad does. I am totally open to other suggestions, since I'm not even sure that is what I want to do. The only distinction is at the type level. So that it will be impossible to write a FlowM that you assume is encrypted, but is not. So if you have a regular FlowM, you know for certain that it is unencrypted. Similar to how the seclib defines classified and unclassified documents as well as trustworthy and untrustworthy users. I like specifying as much as possible in the type system(You probably noticed I'm one of those weirdos that actually like Agda.). It will also allow to write a special show instance for it, so that it decrypts it before printing instead of having to do a runtime check if the particular FlowM is encrypted.

I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best.

I completely agree, although for my use case I absolutely need whole session encryption.

Can we change the mode within the session with as little syntactic overhead as possible?.

Yes, I'll be implementing the secure modifier pretty soon. I've been playing around with websockets and I think that will be finished first, since I want to get your feedback on how we want to deal with secure and inscure flows. I see that it would be best to be as explicit as possible in the type system on the security of a flow, that is why I recommended the EFlowM. As for being explicit about cookie security, I have already started work on that. Very simple, I just created a type synonym.

data EncryptedCookie = Cookie

That will probably land in the next update for cookies. But since that will require quite a bit of hacking, I waited off on adding it to the current pull request. Regular cookies and encrypted cookies are treated at the type level exactly the same right now, because they have the exact same type, namely Cookie. I feel having that explicit distinction will make it much easier for developers to reason about code security, not just that but ghc will enforce the security!

You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

Absolutely, that is exactly what I am going for. The biggest changes will probably occur when I create the explicit encryption distinctions for cookies and flows(If that is what I actually do.). But my goal is to have all of the existing functionality work with the encrypted parts with minimal modification.

On Thu, Jan 2, 2014 at 2:17 PM, agocorona notifications@github.com wrote:

I aistis.

I confess that I have no expertise on security. It is hard to take a design decission with this limitation. I took a look at the article that you linked and I have no clue of how it works. To be syncere I really hate to think about security problems. That's why when you appeared I though that my prayers had been answered ;)

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

What the EFLowM monad will do?. I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best. Can we change the mode within the session with as little syntactic overhead as possible?. You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

2014/1/2 Aistis Raulinaitis notifications@github.com

I think that creating a encrypted FlowM would also help in simplifying the implementation of the secure modifier. It would simply be a function from FlowM -> EFlowM. Just a suggestion, I'm not sure if that is the direction you want to go.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31458104> .

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31489774 .

[sheganinans]

Oh, also. I feel that using Darcs and http://hub.darcs.net/ would be better than git! We should just setup github to mirror the darcs repo.

On Thu, Jan 2, 2014 at 6:00 PM, Aistis Raulinaitis sheganinans@gmail.comwrote:

I confess that I have no expertise on security. It is hard to take a design decission with this limitation.

Good, I have quite a bit of experience with security. So that means you can focus on doing the high-level things you have been doing already!

I took a look at the article that you linked and I have no clue of how it works.

No worries, it's pretty simple. Although I don't think I would use it for MFlow. It was just an example of a good separation of "classified" and "declassified" information. It allows for the type system to enforce the safety of the information at compile time. Not exactly related to what we are doing hear!

To be syncere I really hate to think about security problems.

Well, I guess I'll continue on being the janitor/security guard! :D

That's why when you appeared I though that my prayers had been answered ;)

Good because I would tell you the exact same thing! I was blown away by seaside, nagare, and others. I wanted to see a similar web framework in Haskell, otherwise I would have had to write it myself! Not only that, but MFlow is in many ways better than what I had in mind! So it's a big win for me since you already did the work, and I want to use MFlow for real world applications.

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

Alright! I hope you like what I come up with!

What the EFLowM monad will do?.

Exactly what the regular FlowM monad does. I am totally open to other suggestions, since I'm not even sure that is what I want to do. The only distinction is at the type level. So that it will be impossible to write a FlowM that you assume is encrypted, but is not. So if you have a regular FlowM, you know for certain that it is unencrypted. Similar to how the seclib defines classified and unclassified documents as well as trustworthy and untrustworthy users. I like specifying as much as possible in the type system(You probably noticed I'm one of those weirdos that actually like Agda.). It will also allow to write a special show instance for it, so that it decrypts it before printing instead of having to do a runtime check if the particular FlowM is encrypted.

I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best.

I completely agree, although for my use case I absolutely need whole session encryption.

Can we change the mode within the session with as little syntactic overhead as possible?.

Yes, I'll be implementing the secure modifier pretty soon. I've been playing around with websockets and I think that will be finished first, since I want to get your feedback on how we want to deal with secure and inscure flows. I see that it would be best to be as explicit as possible in the type system on the security of a flow, that is why I recommended the EFlowM. As for being explicit about cookie security, I have already started work on that. Very simple, I just created a type synonym.

data EncryptedCookie = Cookie

That will probably land in the next update for cookies. But since that will require quite a bit of hacking, I waited off on adding it to the current pull request. Regular cookies and encrypted cookies are treated at the type level exactly the same right now, because they have the exact same type, namely Cookie. I feel having that explicit distinction will make it much easier for developers to reason about code security, not just that but ghc will enforce the security!

You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

Absolutely, that is exactly what I am going for. The biggest changes will probably occur when I create the explicit encryption distinctions for cookies and flows(If that is what I actually do.). But my goal is to have all of the existing functionality work with the encrypted parts with minimal modification.

On Thu, Jan 2, 2014 at 2:17 PM, agocorona notifications@github.comwrote:

I aistis.

I confess that I have no expertise on security. It is hard to take a design decission with this limitation. I took a look at the article that you linked and I have no clue of how it works. To be syncere I really hate to think about security problems. That's why when you appeared I though that my prayers had been answered ;)

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

What the EFLowM monad will do?. I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best. Can we change the mode within the session with as little syntactic overhead as possible?. You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

2014/1/2 Aistis Raulinaitis notifications@github.com

I think that creating a encrypted FlowM would also help in simplifying the implementation of the secure modifier. It would simply be a function from FlowM -> EFlowM. Just a suggestion, I'm not sure if that is the direction you want to go.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31458104> .

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31489774 .

[agocorona]

(I´m finishing the article for the Monad Reader and I´m busy with that and some other things this week)

Fine. I see that you got it right.

There would be some duplication of code with the EFLowM monad in "MFlow.Forms.Internals.hs". I suppose i.e.class instances. We have to avoid as much code duplication as possible. I hate it. It is the part of the idea the I like less.

But wait, as i remember, MonadLoc does no rely on Show instances. It transcribe literal lines of code that get at precompilation time. Where the cookie is printed? It should not be printed whatsoever. Well I know that this is not so, because you tell me, and I´m lo lazy to verify what I said about MonadLoc ;)

Remember that there are calls in Widgets, for example edTemplate, that look if the user is authorized and the user name comes from the cookie via the Token data in MFlow. It is necessary to unencript it when appropriate automatically (not to pass the responsibiility to edTemplate or any other existing call.) Although you know that. I´m surprised how fast you got familiar with the code.

From Sunday on I will have more time and will be more talkative. Sorry for the delays.

2014/1/3 Aistis Raulinaitis notifications@github.com

I confess that I have no expertise on security. It is hard to take a design decission with this limitation.

Good, I have quite a bit of experience with security. So that means you can focus on doing the high-level things you have been doing already!

I took a look at the article that you linked and I have no clue of how it works.

No worries, it's pretty simple. Although I don't think I would use it for MFlow. It was just an example of a good separation of "classified" and "declassified" information. It allows for the type system to enforce the safety of the information at compile time. Not exactly related to what we are doing hear!

To be syncere I really hate to think about security problems.

Well, I guess I'll continue on being the janitor/security guard! :D

That's why when you appeared I though that my prayers had been answered ;)

Good because I would tell you the exact same thing! I was blown away by seaside, nagare, and others. I wanted to see a similar web framework in Haskell, otherwise I would have had to write it myself! Not only that, but MFlow is in many ways better than what I had in mind! So it's a big win for me since you already did the work, and I want to use MFlow for real world applications.

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

Alright! I hope you like what I come up with!

What the EFLowM monad will do?.

Exactly what the regular FlowM monad does. I am totally open to other suggestions, since I'm not even sure that is what I want to do. The only distinction is at the type level. So that it will be impossible to write a FlowM that you assume is encrypted, but is not. So if you have a regular FlowM, you know for certain that it is unencrypted. Similar to how the seclib defines classified and unclassified documents as well as trustworthy and untrustworthy users. I like specifying as much as possible in the type system(You probably noticed I'm one of those weirdos that actually like Agda.). It will also allow to write a special show instance for it, so that it decrypts it before printing instead of having to do a runtime check if the particular FlowM is encrypted.

I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best.

I completely agree, although for my use case I absolutely need whole session encryption.

Can we change the mode within the session with as little syntactic overhead as possible?.

Yes, I'll be implementing the secure modifier pretty soon. I've been playing around with websockets and I think that will be finished first, since I want to get your feedback on how we want to deal with secure and inscure flows. I see that it would be best to be as explicit as possible in the type system on the security of a flow, that is why I recommended the EFlowM. As for being explicit about cookie security, I have already started work on that. Very simple, I just created a type synonym.

data EncryptedCookie = Cookie

That will probably land in the next update for cookies. But since that will require quite a bit of hacking, I waited off on adding it to the current pull request. Regular cookies and encrypted cookies are treated at the type level exactly the same right now, because they have the exact same type, namely Cookie. I feel having that explicit distinction will make it much easier for developers to reason about code security, not just that but ghc will enforce the security!

You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

Absolutely, that is exactly what I am going for. The biggest changes will probably occur when I create the explicit encryption distinctions for cookies and flows(If that is what I actually do.). But my goal is to have all of the existing functionality work with the encrypted parts with minimal modification.

On Thu, Jan 2, 2014 at 2:17 PM, agocorona notifications@github.com wrote:

I aistis.

I confess that I have no expertise on security. It is hard to take a design decission with this limitation. I took a look at the article that you linked and I have no clue of how it works. To be syncere I really hate to think about security problems. That's why when you appeared I though that my prayers had been answered ;)

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

What the EFLowM monad will do?. I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best. Can we change the mode within the session with as little syntactic overhead as possible?. You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

2014/1/2 Aistis Raulinaitis notifications@github.com

I think that creating a encrypted FlowM would also help in simplifying the implementation of the secure modifier. It would simply be a function from FlowM -> EFlowM. Just a suggestion, I'm not sure if that is the direction you want to go.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31458104> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31489774> .

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31500891 .

Alberto.

[agocorona]

I used darcs time ago and I suspect that I would be even more clumsy using darcs than git. But you may tell me how to mirror the darcs repo

2014/1/3 Aistis Raulinaitis notifications@github.com

Oh, also. I feel that using Darcs and http://hub.darcs.net/ would be better than git! We should just setup github to mirror the darcs repo.

On Thu, Jan 2, 2014 at 6:00 PM, Aistis Raulinaitis sheganinans@gmail.comwrote:

I confess that I have no expertise on security. It is hard to take a design decission with this limitation.

Good, I have quite a bit of experience with security. So that means you can focus on doing the high-level things you have been doing already!

I took a look at the article that you linked and I have no clue of how it works.

No worries, it's pretty simple. Although I don't think I would use it for MFlow. It was just an example of a good separation of "classified" and "declassified" information. It allows for the type system to enforce the safety of the information at compile time. Not exactly related to what we are doing hear!

To be syncere I really hate to think about security problems.

Well, I guess I'll continue on being the janitor/security guard! :D

That's why when you appeared I though that my prayers had been answered ;)

Good because I would tell you the exact same thing! I was blown away by seaside, nagare, and others. I wanted to see a similar web framework in Haskell, otherwise I would have had to write it myself! Not only that, but MFlow is in many ways better than what I had in mind! So it's a big win for me since you already did the work, and I want to use MFlow for real world applications.

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

Alright! I hope you like what I come up with!

What the EFLowM monad will do?.

Exactly what the regular FlowM monad does. I am totally open to other suggestions, since I'm not even sure that is what I want to do. The only distinction is at the type level. So that it will be impossible to write a FlowM that you assume is encrypted, but is not. So if you have a regular FlowM, you know for certain that it is unencrypted. Similar to how the seclib defines classified and unclassified documents as well as trustworthy and untrustworthy users. I like specifying as much as possible in the type system(You probably noticed I'm one of those weirdos that actually like Agda.). It will also allow to write a special show instance for it, so that it decrypts it before printing instead of having to do a runtime check if the particular FlowM is encrypted.

I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best.

I completely agree, although for my use case I absolutely need whole session encryption.

Can we change the mode within the session with as little syntactic overhead as possible?.

Yes, I'll be implementing the secure modifier pretty soon. I've been playing around with websockets and I think that will be finished first, since I want to get your feedback on how we want to deal with secure and inscure flows. I see that it would be best to be as explicit as possible in the type system on the security of a flow, that is why I recommended the EFlowM. As for being explicit about cookie security, I have already started work on that. Very simple, I just created a type synonym.

data EncryptedCookie = Cookie

That will probably land in the next update for cookies. But since that will require quite a bit of hacking, I waited off on adding it to the current pull request. Regular cookies and encrypted cookies are treated at the type level exactly the same right now, because they have the exact same type, namely Cookie. I feel having that explicit distinction will make it much easier for developers to reason about code security, not just that but ghc will enforce the security!

You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

Absolutely, that is exactly what I am going for. The biggest changes will probably occur when I create the explicit encryption distinctions for cookies and flows(If that is what I actually do.). But my goal is to have all of the existing functionality work with the encrypted parts with minimal modification.

On Thu, Jan 2, 2014 at 2:17 PM, agocorona notifications@github.comwrote:

I aistis.

I confess that I have no expertise on security. It is hard to take a design decission with this limitation. I took a look at the article that you linked and I have no clue of how it works. To be syncere I really hate to think about security problems. That's why when you appeared I though that my prayers had been answered ;)

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

What the EFLowM monad will do?. I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best. Can we change the mode within the session with as little syntactic overhead as possible?. You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

2014/1/2 Aistis Raulinaitis notifications@github.com

I think that creating a encrypted FlowM would also help in simplifying the implementation of the secure modifier. It would simply be a function from FlowM -> EFlowM. Just a suggestion, I'm not sure if that is the direction you want to go.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31458104> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31489774> .

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31504297 .

Alberto.

[sheganinans]

Alright, good! Sunday fits better with my current schedule as well! I definitely want to hear details before I go and start something that you wont want later.

On Fri, Jan 3, 2014 at 2:24 PM, agocorona notifications@github.com wrote:

I used darcs time ago and I suspect that I would be even more clumsy using darcs than git. But you may tell me how to mirror the darcs repo

2014/1/3 Aistis Raulinaitis notifications@github.com

Oh, also. I feel that using Darcs and http://hub.darcs.net/ would be better than git! We should just setup github to mirror the darcs repo.

On Thu, Jan 2, 2014 at 6:00 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

I confess that I have no expertise on security. It is hard to take a design decission with this limitation.

Good, I have quite a bit of experience with security. So that means you can focus on doing the high-level things you have been doing already!

I took a look at the article that you linked and I have no clue of how it works.

No worries, it's pretty simple. Although I don't think I would use it for MFlow. It was just an example of a good separation of "classified" and "declassified" information. It allows for the type system to enforce the safety of the information at compile time. Not exactly related to what we are doing hear!

To be syncere I really hate to think about security problems.

Well, I guess I'll continue on being the janitor/security guard! :D

That's why when you appeared I though that my prayers had been answered ;)

Good because I would tell you the exact same thing! I was blown away by seaside, nagare, and others. I wanted to see a similar web framework in Haskell, otherwise I would have had to write it myself! Not only that, but MFlow is in many ways better than what I had in mind! So it's a big win for me since you already did the work, and I want to use MFlow for real world applications.

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

Alright! I hope you like what I come up with!

What the EFLowM monad will do?.

Exactly what the regular FlowM monad does. I am totally open to other suggestions, since I'm not even sure that is what I want to do. The only distinction is at the type level. So that it will be impossible to write a FlowM that you assume is encrypted, but is not. So if you have a regular FlowM, you know for certain that it is unencrypted. Similar to how the seclib defines classified and unclassified documents as well as trustworthy and untrustworthy users. I like specifying as much as possible in the type system(You probably noticed I'm one of those weirdos that actually like Agda.). It will also allow to write a special show instance for it, so that it decrypts it before printing instead of having to do a runtime check if the particular FlowM is encrypted.

I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best.

I completely agree, although for my use case I absolutely need whole session encryption.

Can we change the mode within the session with as little syntactic overhead as possible?.

Yes, I'll be implementing the secure modifier pretty soon. I've been playing around with websockets and I think that will be finished first, since I want to get your feedback on how we want to deal with secure and inscure flows. I see that it would be best to be as explicit as possible in the type system on the security of a flow, that is why I recommended the EFlowM. As for being explicit about cookie security, I have already started work on that. Very simple, I just created a type synonym.

data EncryptedCookie = Cookie

That will probably land in the next update for cookies. But since that will require quite a bit of hacking, I waited off on adding it to the current pull request. Regular cookies and encrypted cookies are treated at the type level exactly the same right now, because they have the exact same type, namely Cookie. I feel having that explicit distinction will make it much easier for developers to reason about code security, not just that but ghc will enforce the security!

You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

Absolutely, that is exactly what I am going for. The biggest changes will probably occur when I create the explicit encryption distinctions for cookies and flows(If that is what I actually do.). But my goal is to have all of the existing functionality work with the encrypted parts with minimal modification.

On Thu, Jan 2, 2014 at 2:17 PM, agocorona notifications@github.comwrote:

I aistis.

I confess that I have no expertise on security. It is hard to take a design decission with this limitation. I took a look at the article that you linked and I have no clue of how it works. To be syncere I really hate to think about security problems. That's why when you appeared I though that my prayers had been answered ;)

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

What the EFLowM monad will do?. I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best. Can we change the mode within the session with as little syntactic overhead as possible?. You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

2014/1/2 Aistis Raulinaitis notifications@github.com

I think that creating a encrypted FlowM would also help in simplifying the implementation of the secure modifier. It would simply be a function from FlowM -> EFlowM. Just a suggestion, I'm not sure if that is the direction you want to go.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31458104> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31489774> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31504297> .

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31558833 .

[agocorona]

Ok.

Bu the way, did you have an example of use of MFlow with ACID state?. Please send it to me. We can put it in the MFlow demos site...

2014/1/3 Aistis Raulinaitis notifications@github.com

Alright, good! Sunday fits better with my current schedule as well! I definitely want to hear details before I go and start something that you wont want later.

On Fri, Jan 3, 2014 at 2:24 PM, agocorona notifications@github.com wrote:

I used darcs time ago and I suspect that I would be even more clumsy using darcs than git. But you may tell me how to mirror the darcs repo

2014/1/3 Aistis Raulinaitis notifications@github.com

Oh, also. I feel that using Darcs and http://hub.darcs.net/ would be better than git! We should just setup github to mirror the darcs repo.

On Thu, Jan 2, 2014 at 6:00 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

I confess that I have no expertise on security. It is hard to take a design decission with this limitation.

Good, I have quite a bit of experience with security. So that means you can focus on doing the high-level things you have been doing already!

I took a look at the article that you linked and I have no clue of how it works.

No worries, it's pretty simple. Although I don't think I would use it for MFlow. It was just an example of a good separation of "classified" and "declassified" information. It allows for the type system to enforce the safety of the information at compile time. Not exactly related to what we are doing hear!

To be syncere I really hate to think about security problems.

Well, I guess I'll continue on being the janitor/security guard! :D

That's why when you appeared I though that my prayers had been answered ;)

Good because I would tell you the exact same thing! I was blown away by seaside, nagare, and others. I wanted to see a similar web framework in Haskell, otherwise I would have had to write it myself! Not only that, but MFlow is in many ways better than what I had in mind! So it's a big win for me since you already did the work, and I want to use MFlow for real world applications.

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

Alright! I hope you like what I come up with!

What the EFLowM monad will do?.

Exactly what the regular FlowM monad does. I am totally open to other suggestions, since I'm not even sure that is what I want to do. The only distinction is at the type level. So that it will be impossible to write a FlowM that you assume is encrypted, but is not. So if you have a regular FlowM, you know for certain that it is unencrypted. Similar to how the seclib defines classified and unclassified documents as well as trustworthy and untrustworthy users. I like specifying as much as possible in the type system(You probably noticed I'm one of those weirdos that actually like Agda.). It will also allow to write a special show instance for it, so that it decrypts it before printing instead of having to do a runtime check if the particular FlowM is encrypted.

I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best.

I completely agree, although for my use case I absolutely need whole session encryption.

Can we change the mode within the session with as little syntactic overhead as possible?.

Yes, I'll be implementing the secure modifier pretty soon. I've been playing around with websockets and I think that will be finished first, since I want to get your feedback on how we want to deal with secure and inscure flows. I see that it would be best to be as explicit as possible in the type system on the security of a flow, that is why I recommended the EFlowM. As for being explicit about cookie security, I have already started work on that. Very simple, I just created a type synonym.

data EncryptedCookie = Cookie

That will probably land in the next update for cookies. But since that will require quite a bit of hacking, I waited off on adding it to the current pull request. Regular cookies and encrypted cookies are treated at the type level exactly the same right now, because they have the exact same type, namely Cookie. I feel having that explicit distinction will make it much easier for developers to reason about code security, not just that but ghc will enforce the security!

You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

Absolutely, that is exactly what I am going for. The biggest changes will probably occur when I create the explicit encryption distinctions for cookies and flows(If that is what I actually do.). But my goal is to have all of the existing functionality work with the encrypted parts with minimal modification.

On Thu, Jan 2, 2014 at 2:17 PM, agocorona notifications@github.comwrote:

I aistis.

I confess that I have no expertise on security. It is hard to take a design decission with this limitation. I took a look at the article that you linked and I have no clue of how it works. To be syncere I really hate to think about security problems. That's why when you appeared I though that my prayers had been answered ;)

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

What the EFLowM monad will do?. I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best. Can we change the mode within the session with as little syntactic overhead as possible?. You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

2014/1/2 Aistis Raulinaitis notifications@github.com

I think that creating a encrypted FlowM would also help in simplifying the implementation of the secure modifier. It would simply be a function from FlowM -> EFlowM. Just a suggestion, I'm not sure if that is the direction you want to go.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31458104> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31489774> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31504297> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31558833> .

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31560524 .

Alberto.

[agocorona]

Hi Aistis.

How are you?. I miss your messages. Now I have more time.

Yesterday I took a look at information about security problems in web applications. In particular the OWASP top 10 security vulnerabilities And the two first clearly indicate that a mixing http and https in a single session is a security hole, since in MFlow the session Id can be stolen in the non secure part of the flow and used to impersonate the whole session by another user. So IMHO runSecureNavigation that you did is what we need.

My "secure" modifier is not necesary and is dangerous.

So in my opinion we must not mix secure and insecure sessions.

If an application has a mix of confidential information and pure informative and public pages to display with http, the best option is to create anoter application with another host name, with his own cookies and thus with its own session ID. Two applications for the two kind of data. and using static links between them.

2014/1/5 Alberto G. Corona agocorona@gmail.com

Ok.

Bu the way, did you have an example of use of MFlow with ACID state?. Please send it to me. We can put it in the MFlow demos site...

2014/1/3 Aistis Raulinaitis notifications@github.com

Alright, good! Sunday fits better with my current schedule as well! I definitely want to hear details before I go and start something that you wont want later.

On Fri, Jan 3, 2014 at 2:24 PM, agocorona notifications@github.com wrote:

I used darcs time ago and I suspect that I would be even more clumsy using darcs than git. But you may tell me how to mirror the darcs repo

2014/1/3 Aistis Raulinaitis notifications@github.com

Oh, also. I feel that using Darcs and http://hub.darcs.net/ would be better than git! We should just setup github to mirror the darcs repo.

On Thu, Jan 2, 2014 at 6:00 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

I confess that I have no expertise on security. It is hard to take a design decission with this limitation.

Good, I have quite a bit of experience with security. So that means you can focus on doing the high-level things you have been doing already!

I took a look at the article that you linked and I have no clue of how it works.

No worries, it's pretty simple. Although I don't think I would use it for MFlow. It was just an example of a good separation of "classified" and "declassified" information. It allows for the type system to enforce the safety of the information at compile time. Not exactly related to what we are doing hear!

To be syncere I really hate to think about security problems.

Well, I guess I'll continue on being the janitor/security guard! :D

That's why when you appeared I though that my prayers had been answered ;)

Good because I would tell you the exact same thing! I was blown away by seaside, nagare, and others. I wanted to see a similar web framework in Haskell, otherwise I would have had to write it myself! Not only that, but MFlow is in many ways better than what I had in mind! So it's a big win for me since you already did the work, and I want to use MFlow for real world applications.

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

Alright! I hope you like what I come up with!

What the EFLowM monad will do?.

Exactly what the regular FlowM monad does. I am totally open to other suggestions, since I'm not even sure that is what I want to do. The only distinction is at the type level. So that it will be impossible to write a FlowM that you assume is encrypted, but is not. So if you have a regular FlowM, you know for certain that it is unencrypted. Similar to how the seclib defines classified and unclassified documents as well as trustworthy and untrustworthy users. I like specifying as much as possible in the type system(You probably noticed I'm one of those weirdos that actually like Agda.). It will also allow to write a special show instance for it, so that it decrypts it before printing instead of having to do a runtime check if the particular FlowM is encrypted.

I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best.

I completely agree, although for my use case I absolutely need whole session encryption.

Can we change the mode within the session with as little syntactic overhead as possible?.

Yes, I'll be implementing the secure modifier pretty soon. I've been playing around with websockets and I think that will be finished first, since I want to get your feedback on how we want to deal with secure and inscure flows. I see that it would be best to be as explicit as possible in the type system on the security of a flow, that is why I recommended the EFlowM. As for being explicit about cookie security, I have already started work on that. Very simple, I just created a type synonym.

data EncryptedCookie = Cookie

That will probably land in the next update for cookies. But since that will require quite a bit of hacking, I waited off on adding it to the current pull request. Regular cookies and encrypted cookies are treated at the type level exactly the same right now, because they have the exact same type, namely Cookie. I feel having that explicit distinction will make it much easier for developers to reason about code security, not just that but ghc will enforce the security!

You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

Absolutely, that is exactly what I am going for. The biggest changes will probably occur when I create the explicit encryption distinctions for cookies and flows(If that is what I actually do.). But my goal is to have all of the existing functionality work with the encrypted parts with minimal modification.

On Thu, Jan 2, 2014 at 2:17 PM, agocorona notifications@github.comwrote:

I aistis.

I confess that I have no expertise on security. It is hard to take a design decission with this limitation. I took a look at the article that you linked and I have no clue of how it works. To be syncere I really hate to think about security problems. That's why when you appeared I though that my prayers had been answered ;)

The general design assumptions must be valid for the security problem: The less API surface possible with the most flexible and powerful security primitives configurable by means of modifiers. And as much ortogonality as possible. Besides that, I leave the decissions to you.

What the EFLowM monad will do?. I understand that encripting the whole session, may be bad for performance in high load conditions. It may be mandatory for many cases to encrypt the whole session, but IMHO a mixed encripted for sensible infomation and unencripted for others in the same session is the best. Can we change the mode within the session with as little syntactic overhead as possible?. You know better the problem and the solutions than me. I had the hope to solve the security problem in the most ortogonal way possible without disrupting the rest of the functionalities and I think that you agree.

2014/1/2 Aistis Raulinaitis notifications@github.com

I think that creating a encrypted FlowM would also help in simplifying the implementation of the secure modifier. It would simply be a function from FlowM -> EFlowM. Just a suggestion, I'm not sure if that is the direction you want to go.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31458104> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31489774> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31504297> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31558833> .

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31560524 .

Alberto.

Alberto.

[sheganinans]

I've decided to close this pull request since there are too many features that have accumulated. I'll be creating some branches and then having a more orderly pull cycle. (Or just switch to Darcs and work in the wonderful world of unordered patches!)

[sheganinans]

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

[agocorona]

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31727555 .

Alberto.

[agocorona]

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31727555 .

Alberto.

Alberto.

[agocorona]

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31727555 .

Alberto.

Alberto.

Alberto.

[agocorona]

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31727555 .

Alberto.

Alberto.

Alberto.

Alberto.

[sheganinans]

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona notifications@github.com wrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555> .

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31765163 .

[sheganinans]

WoooHoo! That line seems to have fixed the travis build! Thanks a bunch!

On Tue, Jan 7, 2014 at 11:46 AM, Aistis Raulinaitis sheganinans@gmail.comwrote:

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona notifications@github.comwrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555> .

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31765163 .

[sheganinans]

Oh, you may want to add a little build image to your README, just like I did on my fork. http://about.travis-ci.org/docs/user/status-images/

On Tue, Jan 7, 2014 at 11:49 AM, Aistis Raulinaitis sheganinans@gmail.comwrote:

WoooHoo! That line seems to have fixed the travis build! Thanks a bunch!

On Tue, Jan 7, 2014 at 11:46 AM, Aistis Raulinaitis <sheganinans@gmail.com

wrote:

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona notifications@github.comwrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555> .

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31765163 .

[agocorona]

fpcomplete has just published a post about MFlow, taking me and my tutorial about integration as a guest post:

(and gave me 500$ as runner-up price in the haskell competition. my fist money won with Haskell!....

https://www.fpcomplete.com/business/blog/guest-post-solve-integration-problem/

You said that you plan to use MFlow for comercial projects? I was too busy to ask about it before....

2014/1/7 Aistis Raulinaitis notifications@github.com

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona notifications@github.com wrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555> .

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31765163> .

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31771993 .

Alberto.

[sheganinans]

Congratulations! Yes, I have some ideas. I'll send them to you in an email!

On Tue, Jan 7, 2014 at 1:31 PM, agocorona notifications@github.com wrote:

fpcomplete has just published a post about MFlow, taking me and my tutorial about integration as a guest post:

(and gave me 500$ as runner-up price in the haskell competition. my fist money won with Haskell!....

https://www.fpcomplete.com/business/blog/guest-post-solve-integration-problem/

You said that you plan to use MFlow for comercial projects? I was too busy to ask about it before....

2014/1/7 Aistis Raulinaitis notifications@github.com

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona notifications@github.com wrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555> .

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31765163> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31771993> .

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31781664 .

[sheganinans]

Oh, and here is the acid-state demo: https://github.com/sheganinans/MFlow/blob/master/Demos/Acid-State.hs

[sheganinans]

It works great, but as you can see, you have to manually string through the db. I have some ideas on how to make this better, but at his point they are very vague. I was thinking TH, but that is probably overkill. Your thoughts?

[sheganinans]

Oh, and probably in the next update there will be a new formlet for telephone numbers. So that it focuses your cursor on the next input box when a set length is met. I'll even include a way to set the number of fields and all the individual lengths.

Something like:

data TelephoneFields = [FieldLength] data FieldLength = Integer

So a list passed in such as [1,3,3,4] will represent the US numbering system. Ie: |1| |555| |555| |5555|

I think the widget system will do well eventually being broken out into its own package. I'm sure a lot of components would do well being broken out.

On Tue, Jan 7, 2014 at 2:42 PM, Aistis Raulinaitis sheganinans@gmail.comwrote:

Congratulations! Yes, I have some ideas. I'll send them to you in an email!

On Tue, Jan 7, 2014 at 1:31 PM, agocorona notifications@github.comwrote:

fpcomplete has just published a post about MFlow, taking me and my tutorial about integration as a guest post:

(and gave me 500$ as runner-up price in the haskell competition. my fist money won with Haskell!....

https://www.fpcomplete.com/business/blog/guest-post-solve-integration-problem/

You said that you plan to use MFlow for comercial projects? I was too busy to ask about it before....

2014/1/7 Aistis Raulinaitis notifications@github.com

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona notifications@github.com wrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555> .

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31765163> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31771993> .

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31781664 .

[sheganinans]

Oh, and also a getEmail formlet, which will use email-check and autorefresh.

On Tue, Jan 7, 2014 at 4:07 PM, Aistis Raulinaitis sheganinans@gmail.comwrote:

Oh, and probably in the next update there will be a new formlet for telephone numbers. So that it focuses your cursor on the next input box when a set length is met. I'll even include a way to set the number of fields and all the individual lengths.

Something like:

data TelephoneFields = [FieldLength] data FieldLength = Integer

So a list passed in such as [1,3,3,4] will represent the US numbering system. Ie: |1| |555| |555| |5555|

I think the widget system will do well eventually being broken out into its own package. I'm sure a lot of components would do well being broken out.

On Tue, Jan 7, 2014 at 2:42 PM, Aistis Raulinaitis sheganinans@gmail.comwrote:

Congratulations! Yes, I have some ideas. I'll send them to you in an email!

On Tue, Jan 7, 2014 at 1:31 PM, agocorona notifications@github.comwrote:

fpcomplete has just published a post about MFlow, taking me and my tutorial about integration as a guest post:

(and gave me 500$ as runner-up price in the haskell competition. my fist money won with Haskell!....

https://www.fpcomplete.com/business/blog/guest-post-solve-integration-problem/

You said that you plan to use MFlow for comercial projects? I was too busy to ask about it before....

2014/1/7 Aistis Raulinaitis notifications@github.com

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona notifications@github.com wrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555> .

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31765163> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31771993> .

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31781664 .

[agocorona]

I will take a look and put it online in the mflowdemo site. I know little about acid state. I will see

2014/1/8 Aistis Raulinaitis notifications@github.com

It works great, but as you can see, you have to manually string through the db. I have some ideas on how to make this better, but at his point they are very vague. I was thinking TH, but that is probably overkill. Your thoughts?

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31790286 .

Alberto.

[agocorona]

That´s fine.

Yes it makes sense to divide Widgets.hs in smaller packages but I wanted to have fewer modules initially because it looks less complex. At least to add these modules: MFlow.Forms.Widgets.Containers, Modifiers, Misc

2014/1/8 Aistis Raulinaitis notifications@github.com

Oh, and probably in the next update there will be a new formlet for telephone numbers. So that it focuses your cursor on the next input box when a set length is met. I'll even include a way to set the number of fields and all the individual lengths.

Something like:

data TelephoneFields = [FieldLength] data FieldLength = Integer

So a list passed in such as [1,3,3,4] will represent the US numbering system. Ie: |1| |555| |555| |5555|

I think the widget system will do well eventually being broken out into its own package. I'm sure a lot of components would do well being broken out.

On Tue, Jan 7, 2014 at 2:42 PM, Aistis Raulinaitis sheganinans@gmail.comwrote:

Congratulations! Yes, I have some ideas. I'll send them to you in an email!

On Tue, Jan 7, 2014 at 1:31 PM, agocorona notifications@github.comwrote:

fpcomplete has just published a post about MFlow, taking me and my tutorial about integration as a guest post:

(and gave me 500$ as runner-up price in the haskell competition. my fist money won with Haskell!....

https://www.fpcomplete.com/business/blog/guest-post-solve-integration-problem/

You said that you plan to use MFlow for comercial projects? I was too busy to ask about it before....

2014/1/7 Aistis Raulinaitis notifications@github.com

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona notifications@github.com

wrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555> .

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31765163> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31771993> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31781664> .

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31793693 .

Alberto.

[agocorona]

That is very nice. It was needed

2014/1/8 Aistis Raulinaitis notifications@github.com

Oh, and also a getEmail formlet, which will use [email-check](

http://hackage.haskell.org/package/check-email-0.1/docs/Network-Email-Check.html)

and autorefresh.

On Tue, Jan 7, 2014 at 4:07 PM, Aistis Raulinaitis sheganinans@gmail.comwrote:

Oh, and probably in the next update there will be a new formlet for telephone numbers. So that it focuses your cursor on the next input box when a set length is met. I'll even include a way to set the number of fields and all the individual lengths.

Something like:

data TelephoneFields = [FieldLength] data FieldLength = Integer

So a list passed in such as [1,3,3,4] will represent the US numbering system. Ie: |1| |555| |555| |5555|

I think the widget system will do well eventually being broken out into its own package. I'm sure a lot of components would do well being broken out.

On Tue, Jan 7, 2014 at 2:42 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Congratulations! Yes, I have some ideas. I'll send them to you in an email!

On Tue, Jan 7, 2014 at 1:31 PM, agocorona notifications@github.comwrote:

fpcomplete has just published a post about MFlow, taking me and my tutorial about integration as a guest post:

(and gave me 500$ as runner-up price in the haskell competition. my fist money won with Haskell!....

https://www.fpcomplete.com/business/blog/guest-post-solve-integration-problem/

You said that you plan to use MFlow for comercial projects? I was too busy to ask about it before....

2014/1/7 Aistis Raulinaitis notifications@github.com

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona notifications@github.com

wrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555> .

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31765163> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31771993> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31781664> .

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31796859 .

Alberto.

[sheganinans]

Great! So I was thinking about how to add backends without having to explicitly pass them around. I was thinking of maybe adding a cache field to MFlowState. I noticed that it already has a field called mfCached, but it's a bool. I was thinking of keeping it, but also adding a backend field which references the db instance. So that there isn't the implicit assumption that TCache is being used. We should also keep in mind that it's not just for just those two, but to keep it agnostic enough to support all these(At least.):

http://hackage.haskell.org/package/groundhog

http://hackage.haskell.org/package/haskelldb

http://hackage.haskell.org/package/HDBC

http://hackage.haskell.org/package/memcache

http://hackage.haskell.org/package/mongoDB

http://hackage.haskell.org/package/persistent

As well as any others I have forgotten. What do you think would be the best course of action in having a modular persistence layer? I really don't know where you want to go with this. But I definitely want to see the ability to seamlessly transfer one object from one database, to the other, to another, to another, and back again, and have guarantees on round-tripping. Being able to use the specific database you need based on your needs and its qualities, and then shoot it off to another database as if that database was exactly the same database. To be more precise, I would see each pair of databases being modeled as an adjunction. Where you have a free and a forgetful functor between the two databases, modeling the migration pathways between the two of them. I'm not an expert in category theory by any means, but I hope that makes some sense!

Have you seen this talk?: http://vimeo.com/12428370

On Wed, Jan 8, 2014 at 12:50 AM, agocorona notifications@github.com wrote:

That is very nice. It was needed

2014/1/8 Aistis Raulinaitis notifications@github.com

Oh, and also a getEmail formlet, which will use [email-check](

http://hackage.haskell.org/package/check-email-0.1/docs/Network-Email-Check.html)

and autorefresh.

On Tue, Jan 7, 2014 at 4:07 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Oh, and probably in the next update there will be a new formlet for telephone numbers. So that it focuses your cursor on the next input box when a set length is met. I'll even include a way to set the number of fields and all the individual lengths.

Something like:

data TelephoneFields = [FieldLength] data FieldLength = Integer

So a list passed in such as [1,3,3,4] will represent the US numbering system. Ie: |1| |555| |555| |5555|

I think the widget system will do well eventually being broken out into its own package. I'm sure a lot of components would do well being broken out.

On Tue, Jan 7, 2014 at 2:42 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Congratulations! Yes, I have some ideas. I'll send them to you in an email!

On Tue, Jan 7, 2014 at 1:31 PM, agocorona notifications@github.comwrote:

fpcomplete has just published a post about MFlow, taking me and my tutorial about integration as a guest post:

(and gave me 500$ as runner-up price in the haskell competition. my fist money won with Haskell!....

https://www.fpcomplete.com/business/blog/guest-post-solve-integration-problem/

You said that you plan to use MFlow for comercial projects? I was too busy to ask about it before....

2014/1/7 Aistis Raulinaitis notifications@github.com

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona < notifications@github.com>

wrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555>

.

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31765163> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31771993> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31781664> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31796859> .

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31814290 .

[sheganinans]

Here are the slides for the talk(I remember the camera work being pretty bad.): http://code.galois.com/talk/2010/10-06-spivak.pdf

There is also a followup talk, which is also excellent: http://vimeo.com/16412423

On Wed, Jan 8, 2014 at 1:33 AM, Aistis Raulinaitis sheganinans@gmail.comwrote:

Great! So I was thinking about how to add backends without having to explicitly pass them around. I was thinking of maybe adding a cache field to MFlowState. I noticed that it already has a field called mfCached, but it's a bool. I was thinking of keeping it, but also adding a backend field which references the db instance. So that there isn't the implicit assumption that TCache is being used. We should also keep in mind that it's not just for just those two, but to keep it agnostic enough to support all these(At least.):

http://hackage.haskell.org/package/groundhog

http://hackage.haskell.org/package/haskelldb

http://hackage.haskell.org/package/HDBC

http://hackage.haskell.org/package/memcache

http://hackage.haskell.org/package/mongoDB

http://hackage.haskell.org/package/persistent

As well as any others I have forgotten. What do you think would be the best course of action in having a modular persistence layer? I really don't know where you want to go with this. But I definitely want to see the ability to seamlessly transfer one object from one database, to the other, to another, to another, and back again, and have guarantees on round-tripping. Being able to use the specific database you need based on your needs and its qualities, and then shoot it off to another database as if that database was exactly the same database. To be more precise, I would see each pair of databases being modeled as an adjunction. Where you have a free and a forgetful functor between the two databases, modeling the migration pathways between the two of them. I'm not an expert in category theory by any means, but I hope that makes some sense!

Have you seen this talk?: http://vimeo.com/12428370

On Wed, Jan 8, 2014 at 12:50 AM, agocorona notifications@github.comwrote:

That is very nice. It was needed

2014/1/8 Aistis Raulinaitis notifications@github.com

Oh, and also a getEmail formlet, which will use [email-check](

http://hackage.haskell.org/package/check-email-0.1/docs/Network-Email-Check.html)

and autorefresh.

On Tue, Jan 7, 2014 at 4:07 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Oh, and probably in the next update there will be a new formlet for telephone numbers. So that it focuses your cursor on the next input box when a set length is met. I'll even include a way to set the number of fields and all the individual lengths.

Something like:

data TelephoneFields = [FieldLength] data FieldLength = Integer

So a list passed in such as [1,3,3,4] will represent the US numbering system. Ie: |1| |555| |555| |5555|

I think the widget system will do well eventually being broken out into its own package. I'm sure a lot of components would do well being broken out.

On Tue, Jan 7, 2014 at 2:42 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Congratulations! Yes, I have some ideas. I'll send them to you in an email!

On Tue, Jan 7, 2014 at 1:31 PM, agocorona notifications@github.comwrote:

fpcomplete has just published a post about MFlow, taking me and my tutorial about integration as a guest post:

(and gave me 500$ as runner-up price in the haskell competition. my fist money won with Haskell!....

https://www.fpcomplete.com/business/blog/guest-post-solve-integration-problem/

You said that you plan to use MFlow for comercial projects? I was too busy to ask about it before....

2014/1/7 Aistis Raulinaitis notifications@github.com

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona < notifications@github.com>

wrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555>

.

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31765163>

.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31771993> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31781664> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31796859> .

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31814290 .

[agocorona]

Unfortunately I´m in My mother`s house, until middle January, and here I have no high speed Internet, so i can not see the videos. I´ll say yo when I have an opportunity.

I imagine that you have a lot of interest in the database layer since your paid work now has a lot to do with it. Do you mean an abstract layer above any database? That is the purpose of Persistent and Groundhog isn´t it?. It is clear that they are ad-hoc and not with category-theoretical foundation however. I personally like databases like I like security: Not much. That is why I created tcache,

mfCached is a temporal flag that indicates that the View monad is processing a cached widget, That means that his rendering in cached in a TCache register in memory and must not be recreated.

Actually Workflow and MFlow uses TCache for many purposes. Cached widget renderings, for example (with wcached or wfreeze) are cached in memory, but not saved to any persistent storage. That is one example. But also the reading and writing of logged events are trough TCache. I love STM and doing transactions in memory, because that assures a high throughput. I think that there is where the transactions should happen. TCache also permits to perform transactions with objects coming from different storages. I can create an application that manage data from a SQL application and from files and from MongoDB/Persistent the three at the same time. It need only a IResource instance to work with TCache. In fact demos-blaze.hs uses TCache registers coming from files and from AWS.

But TCache can be bypassed and anything can be done as you did with acid-state and I did with Persistent. And it is fine. But all of the above, except memcache and acid-state and SQlite, do not cache in memory so all of them can benefit by using TCache.

For the cloud service, I want to create a form of DB-abstract data replication using TCache. I did some non cloud haskell tests for it. That is necessary for the MFlow failover and load distribution mechanism.

2014/1/8 Aistis Raulinaitis notifications@github.com

Here are the slides for the talk(I remember the camera work being pretty bad.): http://code.galois.com/talk/2010/10-06-spivak.pdf

There is also a followup talk, which is also excellent: http://vimeo.com/16412423

On Wed, Jan 8, 2014 at 1:33 AM, Aistis Raulinaitis sheganinans@gmail.comwrote:

Great! So I was thinking about how to add backends without having to explicitly pass them around. I was thinking of maybe adding a cache field to MFlowState. I noticed that it already has a field called mfCached, but it's a bool. I was thinking of keeping it, but also adding a backend field which references the db instance. So that there isn't the implicit assumption that TCache is being used. We should also keep in mind that it's not just for just those two, but to keep it agnostic enough to support all these(At least.):

http://hackage.haskell.org/package/groundhog

http://hackage.haskell.org/package/haskelldb

http://hackage.haskell.org/package/HDBC

http://hackage.haskell.org/package/memcache

http://hackage.haskell.org/package/mongoDB

http://hackage.haskell.org/package/persistent

As well as any others I have forgotten. What do you think would be the best course of action in having a modular persistence layer? I really don't know where you want to go with this. But I definitely want to see the ability to seamlessly transfer one object from one database, to the other, to another, to another, and back again, and have guarantees on round-tripping. Being able to use the specific database you need based on your needs and its qualities, and then shoot it off to another database as if that database was exactly the same database. To be more precise, I would see each pair of databases being modeled as an adjunction. Where you have a free and a forgetful functor between the two databases, modeling the migration pathways between the two of them. I'm not an expert in category theory by any means, but I hope that makes some sense!

Have you seen this talk?: http://vimeo.com/12428370

On Wed, Jan 8, 2014 at 12:50 AM, agocorona notifications@github.comwrote:

That is very nice. It was needed

2014/1/8 Aistis Raulinaitis notifications@github.com

Oh, and also a getEmail formlet, which will use [email-check](

http://hackage.haskell.org/package/check-email-0.1/docs/Network-Email-Check.html)

and autorefresh.

On Tue, Jan 7, 2014 at 4:07 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Oh, and probably in the next update there will be a new formlet for telephone numbers. So that it focuses your cursor on the next input box when a set length is met. I'll even include a way to set the number of fields and all the individual lengths.

Something like:

data TelephoneFields = [FieldLength] data FieldLength = Integer

So a list passed in such as [1,3,3,4] will represent the US numbering system. Ie: |1| |555| |555| |5555|

I think the widget system will do well eventually being broken out into its own package. I'm sure a lot of components would do well being broken out.

On Tue, Jan 7, 2014 at 2:42 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Congratulations! Yes, I have some ideas. I'll send them to you in an email!

On Tue, Jan 7, 2014 at 1:31 PM, agocorona < notifications@github.com>wrote:

fpcomplete has just published a post about MFlow, taking me and my tutorial about integration as a guest post:

(and gave me 500$ as runner-up price in the haskell competition. my fist money won with Haskell!....

https://www.fpcomplete.com/business/blog/guest-post-solve-integration-problem/

You said that you plan to use MFlow for comercial projects? I was too busy to ask about it before....

2014/1/7 Aistis Raulinaitis notifications@github.com

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona < notifications@github.com>

wrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555>

.

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31765163>

.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31771993>

.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31781664> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31796859> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31814290> .

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31816942 .

Alberto.

[sheganinans]

I imagine that you have a lot of interest in the database layer since your paid work now has a lot to do with it. Do you mean an abstract layer above any database? That is the purpose of Persistent and Groundhog isn´t it?. It is clear that they are ad-hoc and not with category-theoretical foundation however. I personally like databases like I like security: Not much. That is why I created tcache,

Yes, you are absolutely right, It is to abstract the database. But my biggest issue is having to manually string the instance of the db through each function, I'm thinking of 2 things. How to make the db instance implicit in the flow, and how to be able to add any db backend to be able to be reference in a flow. As well as mechanisms to give individual flows different backends in their own contexts and to not have to worry about the contexts bleeding into one and other.

mfCached is a temporal flag that indicates that the View monad is processing a cached widget, That means that his rendering in cached in a TCache register in memory and must not be recreated.

So is this more of an internal thing, than a db thing? I'm still trying to figure out how exactly everything works! :D

Actually Workflow and MFlow uses TCache for many purposes. Cached widget renderings, for example (with wcached or wfreeze) are cached in memory, but not saved to any persistent storage. That is one example. But also the reading and writing of logged events are trough TCache. I love STM and doing transactions in memory, because that assures a high throughput. I think that there is where the transactions should happen. TCache also permits to perform transactions with objects coming from different storages. I can create an application that manage data from a SQL application and from files and from MongoDB/Persistent the three at the same time. It need only a IResource instance to work with TCache. In fact demos-blaze.hs uses TCache registers coming from files and from AWS.

Yes, STM is a beautiful thing! Oh, ok. So I'm probably completely misunderstanding what TCache is doing! I think I need to take a closer look at all of this!

But TCache can be bypassed and anything can be done as you did with acid-state and I did with Persistent. And it is fine. But all of the above, except memcache and acid-state and SQlite, do not cache in memory so all of them can benefit by using TCache.

Oh ok! That makes sense! So TCache can be used as a DB, but can also act as an in-memory cache. Thats fantastic! I completely missed what TCache was all about! Very cool! Wow, so you could set up TCache in between the web server and the DB and have it cache highly demanded data? How easy is it to use it with (hyper)graph dbs?

For the cloud service, I want to create a form of DB-abstract data replication using TCache. I did some non cloud haskell tests for it. That is necessary for the MFlow failover and load distribution mechanism.

Very cool! Wow, that would make using TCache a dream!

On Wed, Jan 8, 2014 at 3:05 PM, agocorona notifications@github.com wrote:

Unfortunately I´m in My mother`s house, until middle January, and here I have no high speed Internet, so i can not see the videos. I´ll say yo when I have an opportunity.

I imagine that you have a lot of interest in the database layer since your paid work now has a lot to do with it. Do you mean an abstract layer above any database? That is the purpose of Persistent and Groundhog isn´t it?. It is clear that they are ad-hoc and not with category-theoretical foundation however. I personally like databases like I like security: Not much. That is why I created tcache,

mfCached is a temporal flag that indicates that the View monad is processing a cached widget, That means that his rendering in cached in a TCache register in memory and must not be recreated.

Actually Workflow and MFlow uses TCache for many purposes. Cached widget renderings, for example (with wcached or wfreeze) are cached in memory, but not saved to any persistent storage. That is one example. But also the reading and writing of logged events are trough TCache. I love STM and doing transactions in memory, because that assures a high throughput. I think that there is where the transactions should happen. TCache also permits to perform transactions with objects coming from different storages. I can create an application that manage data from a SQL application and from files and from MongoDB/Persistent the three at the same time. It need only a IResource instance to work with TCache. In fact demos-blaze.hs uses TCache registers coming from files and from AWS.

But TCache can be bypassed and anything can be done as you did with acid-state and I did with Persistent. And it is fine. But all of the above, except memcache and acid-state and SQlite, do not cache in memory so all of them can benefit by using TCache.

For the cloud service, I want to create a form of DB-abstract data replication using TCache. I did some non cloud haskell tests for it. That is necessary for the MFlow failover and load distribution mechanism.

2014/1/8 Aistis Raulinaitis notifications@github.com

Here are the slides for the talk(I remember the camera work being pretty bad.): http://code.galois.com/talk/2010/10-06-spivak.pdf

There is also a followup talk, which is also excellent: http://vimeo.com/16412423

On Wed, Jan 8, 2014 at 1:33 AM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Great! So I was thinking about how to add backends without having to explicitly pass them around. I was thinking of maybe adding a cache field to MFlowState. I noticed that it already has a field called mfCached, but it's a bool. I was thinking of keeping it, but also adding a backend field which references the db instance. So that there isn't the implicit assumption that TCache is being used. We should also keep in mind that it's not just for just those two, but to keep it agnostic enough to support all these(At least.):

http://hackage.haskell.org/package/groundhog

http://hackage.haskell.org/package/haskelldb

http://hackage.haskell.org/package/HDBC

http://hackage.haskell.org/package/memcache

http://hackage.haskell.org/package/mongoDB

http://hackage.haskell.org/package/persistent

As well as any others I have forgotten. What do you think would be the best course of action in having a modular persistence layer? I really don't know where you want to go with this. But I definitely want to see the ability to seamlessly transfer one object from one database, to the other, to another, to another, and back again, and have guarantees on round-tripping. Being able to use the specific database you need based on your needs and its qualities, and then shoot it off to another database as if that database was exactly the same database. To be more precise, I would see each pair of databases being modeled as an adjunction. Where you have a free and a forgetful functor between the two databases, modeling the migration pathways between the two of them. I'm not an expert in category theory by any means, but I hope that makes some sense!

Have you seen this talk?: http://vimeo.com/12428370

On Wed, Jan 8, 2014 at 12:50 AM, agocorona notifications@github.comwrote:

That is very nice. It was needed

2014/1/8 Aistis Raulinaitis notifications@github.com

Oh, and also a getEmail formlet, which will use [email-check](

http://hackage.haskell.org/package/check-email-0.1/docs/Network-Email-Check.html)

and autorefresh.

On Tue, Jan 7, 2014 at 4:07 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Oh, and probably in the next update there will be a new formlet for telephone numbers. So that it focuses your cursor on the next input box when a set length is met. I'll even include a way to set the number of fields and all the individual lengths.

Something like:

data TelephoneFields = [FieldLength] data FieldLength = Integer

So a list passed in such as [1,3,3,4] will represent the US numbering system. Ie: |1| |555| |555| |5555|

I think the widget system will do well eventually being broken out into its own package. I'm sure a lot of components would do well being broken out.

On Tue, Jan 7, 2014 at 2:42 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Congratulations! Yes, I have some ideas. I'll send them to you in an email!

On Tue, Jan 7, 2014 at 1:31 PM, agocorona < notifications@github.com>wrote:

fpcomplete has just published a post about MFlow, taking me and my tutorial about integration as a guest post:

(and gave me 500$ as runner-up price in the haskell competition. my fist money won with Haskell!....

https://www.fpcomplete.com/business/blog/guest-post-solve-integration-problem/

You said that you plan to use MFlow for comercial projects? I was too busy to ask about it before....

2014/1/7 Aistis Raulinaitis notifications@github.com

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona < notifications@github.com>

wrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555>

.

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31765163>

.

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31771993>

.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31781664> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31796859> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31814290> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31816942> .

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31886157 .

[agocorona]

2014/1/9, Aistis Raulinaitis notifications@github.com:

I imagine that you have a lot of interest in the database layer since your paid work now has a lot to do with it. Do you mean an abstract layer above any database? That is the purpose of Persistent and Groundhog isn´t it?. It is clear that they are ad-hoc and not with category-theoretical foundation however. I personally like databases like I like security: Not much. That is why I created tcache,

Yes, you are absolutely right, It is to abstract the database. But my biggest issue is having to manually string the instance of the db through each function, I'm thinking of 2 things. How to make the db instance implicit in the flow, and how to be able to add any db backend to be able to be reference in a flow. As well as mechanisms to give individual flows different backends in their own contexts and to not have to worry about the contexts bleeding into one and other.

mfCached is a temporal flag that indicates that the View monad is processing a cached widget, That means that his rendering in cached in a TCache register in memory and must not be recreated.

So is this more of an internal thing, than a db thing? I'm still trying to figure out how exactly everything works! :D

Actually Workflow and MFlow uses TCache for many purposes. Cached widget renderings, for example (with wcached or wfreeze) are cached in memory, but not saved to any persistent storage. That is one example. But also the reading and writing of logged events are trough TCache. I love STM and doing transactions in memory, because that assures a high throughput. I think that there is where the transactions should happen. TCache also permits to perform transactions with objects coming from different storages. I can create an application that manage data from a SQL application and from files and from MongoDB/Persistent the three at the same time. It need only a IResource instance to work with TCache. In fact demos-blaze.hs uses TCache registers coming from files and from AWS.

Yes, STM is a beautiful thing! Oh, ok. So I'm probably completely misunderstanding what TCache is doing! I think I need to take a closer look at all of this!

But TCache can be bypassed and anything can be done as you did with acid-state and I did with Persistent. And it is fine. But all of the above, except memcache and acid-state and SQlite, do not cache in memory so all of them can benefit by using TCache.

Oh ok! That makes sense! So TCache can be used as a DB, but can also act as an in-memory cache. Thats fantastic! I completely missed what TCache was all about! Very cool! Wow, so you could set up TCache in between the web server and the DB and have it cache highly demanded data? How easy is it to use it with (hyper)graph dbs?

That hypergraph DBs are completely new for me, but if you have a reference in one database register to other, for example a key or a register identifier, that can be converted in a DBRef. DBRefs can be serialized and deserialized. they are like serializable STM variables. they are serialized as key values and deserialized as STM references (DBRefs)

see for example, the example at the top of

http://hackage.haskell.org/package/TCache-0.11.0.0/docs/Data-TCache-IndexQuery.html

There the Car register has a reference to the Owner register. Then It ask for some relations (there are some relational-like and full text search queries).

But, the graph can be navigated trough reading the references (readDBRef) that have more references and so on.

There is an example in the package tcache, called dbref.hs where it navigates trough register references. no relational queries. very simple. but instructive.

For the cloud service, I want to create a form of DB-abstract data replication using TCache. I did some non cloud haskell tests for it. That is necessary for the MFlow failover and load distribution mechanism.

Very cool! Wow, that would make using TCache a dream!

On Wed, Jan 8, 2014 at 3:05 PM, agocorona notifications@github.com wrote:

Unfortunately I´m in My mother`s house, until middle January, and here I have no high speed Internet, so i can not see the videos. I´ll say yo when I have an opportunity.

I imagine that you have a lot of interest in the database layer since your paid work now has a lot to do with it. Do you mean an abstract layer above any database? That is the purpose of Persistent and Groundhog isn´t it?. It is clear that they are ad-hoc and not with category-theoretical foundation however. I personally like databases like I like security: Not much. That is why I created tcache,

mfCached is a temporal flag that indicates that the View monad is processing a cached widget, That means that his rendering in cached in a TCache register in memory and must not be recreated.

Actually Workflow and MFlow uses TCache for many purposes. Cached widget renderings, for example (with wcached or wfreeze) are cached in memory, but not saved to any persistent storage. That is one example. But also the reading and writing of logged events are trough TCache. I love STM and doing transactions in memory, because that assures a high throughput. I think that there is where the transactions should happen. TCache also permits to perform transactions with objects coming from different storages. I can create an application that manage data from a SQL application and from files and from MongoDB/Persistent the three at the same time. It need only a IResource instance to work with TCache. In fact demos-blaze.hs uses TCache registers coming from files and from AWS.

But TCache can be bypassed and anything can be done as you did with acid-state and I did with Persistent. And it is fine. But all of the above, except memcache and acid-state and SQlite, do not cache in memory so all of them can benefit by using TCache.

For the cloud service, I want to create a form of DB-abstract data replication using TCache. I did some non cloud haskell tests for it. That is necessary for the MFlow failover and load distribution mechanism.

2014/1/8 Aistis Raulinaitis notifications@github.com

Here are the slides for the talk(I remember the camera work being pretty bad.): http://code.galois.com/talk/2010/10-06-spivak.pdf

There is also a followup talk, which is also excellent: http://vimeo.com/16412423

On Wed, Jan 8, 2014 at 1:33 AM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Great! So I was thinking about how to add backends without having to explicitly pass them around. I was thinking of maybe adding a cache field to MFlowState. I noticed that it already has a field called mfCached, but it's a bool. I was thinking of keeping it, but also adding a backend field which references the db instance. So that there isn't the implicit assumption that TCache is being used. We should also keep in mind that it's not just for just those two, but to keep it agnostic enough to support all these(At least.):

http://hackage.haskell.org/package/groundhog

http://hackage.haskell.org/package/haskelldb

http://hackage.haskell.org/package/HDBC

http://hackage.haskell.org/package/memcache

http://hackage.haskell.org/package/mongoDB

http://hackage.haskell.org/package/persistent

As well as any others I have forgotten. What do you think would be the best course of action in having a modular persistence layer? I really don't know where you want to go with this. But I definitely want to see the ability to seamlessly transfer one object from one database, to the other, to another, to another, and back again, and have guarantees on round-tripping. Being able to use the specific database you need based on your needs and its qualities, and then shoot it off to another database as if that database was exactly the same database. To be more precise, I would see each pair of databases being modeled as an adjunction. Where you have a free and a forgetful functor between the two databases, modeling the migration pathways between the two of them. I'm not an expert in category theory by any means, but I hope that makes some sense!

Have you seen this talk?: http://vimeo.com/12428370

On Wed, Jan 8, 2014 at 12:50 AM, agocorona notifications@github.comwrote:

That is very nice. It was needed

2014/1/8 Aistis Raulinaitis notifications@github.com

Oh, and also a getEmail formlet, which will use [email-check](

http://hackage.haskell.org/package/check-email-0.1/docs/Network-Email-Check.html)

and autorefresh.

On Tue, Jan 7, 2014 at 4:07 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Oh, and probably in the next update there will be a new formlet for telephone numbers. So that it focuses your cursor on the next input box when a set length is met. I'll even include a way to set the number of fields and all the individual lengths.

Something like:

data TelephoneFields = [FieldLength] data FieldLength = Integer

So a list passed in such as [1,3,3,4] will represent the US numbering system. Ie: |1| |555| |555| |5555|

I think the widget system will do well eventually being broken out into its own package. I'm sure a lot of components would do well being broken out.

On Tue, Jan 7, 2014 at 2:42 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Congratulations! Yes, I have some ideas. I'll send them to you in an email!

On Tue, Jan 7, 2014 at 1:31 PM, agocorona < notifications@github.com>wrote:

fpcomplete has just published a post about MFlow, taking me and my tutorial about integration as a guest post:

(and gave me 500$ as runner-up price in the haskell competition. my fist money won with Haskell!....

https://www.fpcomplete.com/business/blog/guest-post-solve-integration-problem/

You said that you plan to use MFlow for comercial projects? I was too busy to ask about it before....

2014/1/7 Aistis Raulinaitis notifications@github.com

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona < notifications@github.com>

wrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis notifications@github.com

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555>

.

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31765163>

.

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31771993>

.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31781664> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31796859> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31814290> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31816942> .

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31886157 .

---

Reply to this email directly or view it on GitHub: https://github.com/agocorona/MFlow/pull/13#issuecomment-31908055

Alberto.

[sheganinans]

Yes, hypergraphs were pretty mind-blowing when I first encountered them. Luckily a lot of the hard work has been done for us! http://hackage.haskell.org/package/graph-rewriting I'm pretty sure we could fit in a relational representation of hypergraphs using TCache. I'll take a look at all your examples!

On Thu, Jan 9, 2014 at 2:14 PM, agocorona notifications@github.com wrote:

2014/1/9, Aistis Raulinaitis notifications@github.com:

I imagine that you have a lot of interest in the database layer since your paid work now has a lot to do with it. Do you mean an abstract layer above any database? That is the purpose of Persistent and Groundhog isn´t it?. It is clear that they are ad-hoc and not with category-theoretical foundation however. I personally like databases like I like security: Not much. That is why I created tcache,

Yes, you are absolutely right, It is to abstract the database. But my biggest issue is having to manually string the instance of the db through each function, I'm thinking of 2 things. How to make the db instance implicit in the flow, and how to be able to add any db backend to be able to be reference in a flow. As well as mechanisms to give individual flows different backends in their own contexts and to not have to worry about the contexts bleeding into one and other.

mfCached is a temporal flag that indicates that the View monad is processing a cached widget, That means that his rendering in cached in a TCache register in memory and must not be recreated.

So is this more of an internal thing, than a db thing? I'm still trying to figure out how exactly everything works! :D

Actually Workflow and MFlow uses TCache for many purposes. Cached widget renderings, for example (with wcached or wfreeze) are cached in memory, but not saved to any persistent storage. That is one example. But also the reading and writing of logged events are trough TCache. I love STM and doing transactions in memory, because that assures a high throughput. I think that there is where the transactions should happen. TCache also permits to perform transactions with objects coming from different storages. I can create an application that manage data from a SQL application and from files and from MongoDB/Persistent the three at the same time. It need only a IResource instance to work with TCache. In fact demos-blaze.hs uses TCache registers coming from files and from AWS.

Yes, STM is a beautiful thing! Oh, ok. So I'm probably completely misunderstanding what TCache is doing! I think I need to take a closer look at all of this!

But TCache can be bypassed and anything can be done as you did with acid-state and I did with Persistent. And it is fine. But all of the above, except memcache and acid-state and SQlite, do not cache in memory so all of them can benefit by using TCache.

Oh ok! That makes sense! So TCache can be used as a DB, but can also act as an in-memory cache. Thats fantastic! I completely missed what TCache was all about! Very cool! Wow, so you could set up TCache in between the web server and the DB and have it cache highly demanded data? How easy is it to use it with (hyper)graph dbs?

That hypergraph DBs are completely new for me, but if you have a reference in one database register to other, for example a key or a register identifier, that can be converted in a DBRef. DBRefs can be serialized and deserialized. they are like serializable STM variables. they are serialized as key values and deserialized as STM references (DBRefs)

see for example, the example at the top of

http://hackage.haskell.org/package/TCache-0.11.0.0/docs/Data-TCache-IndexQuery.html

There the Car register has a reference to the Owner register. Then It ask for some relations (there are some relational-like and full text search queries).

But, the graph can be navigated trough reading the references (readDBRef) that have more references and so on.

There is an example in the package tcache, called dbref.hs where it navigates trough register references. no relational queries. very simple. but instructive.

For the cloud service, I want to create a form of DB-abstract data replication using TCache. I did some non cloud haskell tests for it. That is necessary for the MFlow failover and load distribution mechanism.

Very cool! Wow, that would make using TCache a dream!

On Wed, Jan 8, 2014 at 3:05 PM, agocorona notifications@github.com wrote:

Unfortunately I´m in My mother`s house, until middle January, and here I have no high speed Internet, so i can not see the videos. I´ll say yo when I have an opportunity.

I imagine that you have a lot of interest in the database layer since your paid work now has a lot to do with it. Do you mean an abstract layer above any database? That is the purpose of Persistent and Groundhog isn´t it?. It is clear that they are ad-hoc and not with category-theoretical foundation however. I personally like databases like I like security: Not much. That is why I created tcache,

mfCached is a temporal flag that indicates that the View monad is processing a cached widget, That means that his rendering in cached in a TCache register in memory and must not be recreated.

Actually Workflow and MFlow uses TCache for many purposes. Cached widget renderings, for example (with wcached or wfreeze) are cached in memory, but not saved to any persistent storage. That is one example. But also the reading and writing of logged events are trough TCache. I love STM and doing transactions in memory, because that assures a high throughput. I think that there is where the transactions should happen. TCache also permits to perform transactions with objects coming from different storages. I can create an application that manage data from a SQL application and from files and from MongoDB/Persistent the three at the same time. It need only a IResource instance to work with TCache. In fact demos-blaze.hs uses TCache registers coming from files and from AWS.

But TCache can be bypassed and anything can be done as you did with acid-state and I did with Persistent. And it is fine. But all of the above, except memcache and acid-state and SQlite, do not cache in memory so all of them can benefit by using TCache.

For the cloud service, I want to create a form of DB-abstract data replication using TCache. I did some non cloud haskell tests for it. That is necessary for the MFlow failover and load distribution mechanism.

2014/1/8 Aistis Raulinaitis notifications@github.com

Here are the slides for the talk(I remember the camera work being pretty bad.): http://code.galois.com/talk/2010/10-06-spivak.pdf

There is also a followup talk, which is also excellent: http://vimeo.com/16412423

On Wed, Jan 8, 2014 at 1:33 AM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Great! So I was thinking about how to add backends without having to explicitly pass them around. I was thinking of maybe adding a cache field to MFlowState. I noticed that it already has a field called mfCached, but it's a bool. I was thinking of keeping it, but also adding a backend field which references the db instance. So that there isn't the implicit assumption that TCache is being used. We should also keep in mind that it's not just for just those two, but to keep it agnostic enough to support all these(At least.):

http://hackage.haskell.org/package/groundhog

http://hackage.haskell.org/package/haskelldb

http://hackage.haskell.org/package/HDBC

http://hackage.haskell.org/package/memcache

http://hackage.haskell.org/package/mongoDB

http://hackage.haskell.org/package/persistent

As well as any others I have forgotten. What do you think would be the best course of action in having a modular persistence layer? I really don't know where you want to go with this. But I definitely want to see the ability to seamlessly transfer one object from one database, to the other, to another, to another, and back again, and have guarantees on round-tripping. Being able to use the specific database you need based on your needs and its qualities, and then shoot it off to another database as if that database was exactly the same database. To be more precise, I would see each pair of databases being modeled as an adjunction. Where you have a free and a forgetful functor between the two databases, modeling the migration pathways between the two of them. I'm not an expert in category theory by any means, but I hope that makes some sense!

Have you seen this talk?: http://vimeo.com/12428370

On Wed, Jan 8, 2014 at 12:50 AM, agocorona notifications@github.comwrote:

That is very nice. It was needed

2014/1/8 Aistis Raulinaitis notifications@github.com

Oh, and also a getEmail formlet, which will use [email-check](

http://hackage.haskell.org/package/check-email-0.1/docs/Network-Email-Check.html)

and autorefresh.

On Tue, Jan 7, 2014 at 4:07 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Oh, and probably in the next update there will be a new formlet for telephone numbers. So that it focuses your cursor on the next input box when a set length is met. I'll even include a way to set the number of fields and all the individual lengths.

Something like:

data TelephoneFields = [FieldLength] data FieldLength = Integer

So a list passed in such as [1,3,3,4] will represent the US numbering system. Ie: |1| |555| |555| |5555|

I think the widget system will do well eventually being broken out into its own package. I'm sure a lot of components would do well being broken out.

On Tue, Jan 7, 2014 at 2:42 PM, Aistis Raulinaitis < sheganinans@gmail.com>wrote:

Congratulations! Yes, I have some ideas. I'll send them to you in an email!

On Tue, Jan 7, 2014 at 1:31 PM, agocorona < notifications@github.com>wrote:

fpcomplete has just published a post about MFlow, taking me and my tutorial about integration as a guest post:

(and gave me 500$ as runner-up price in the haskell competition. my fist money won with Haskell!....

https://www.fpcomplete.com/business/blog/guest-post-solve-integration-problem/

You said that you plan to use MFlow for comercial projects? I was too busy to ask about it before....

2014/1/7 Aistis Raulinaitis notifications@github.com

I will take a look and install darcshub. that update out of sequence is very nice.

Yes, I absolutely believe that Darc's patch system is much better to deal with than the convolutions of git's forks, branches, and commits.

about EFlowM, in FlowM, there are a lot of instances and I plan to drop them away of MFlow ad put them in the package supervisor, that in essence is the FlowM monad. It is in Hackage. Take a look at it if you like. If we duplicate the code for SFlowM that would complicate the extraction and still we would need to derive SFlowM form Supervisor.

Ok, then maybe we should hold off until everything is extracted? What is your timescale on this? I have other things I can add instead of the type level enforcement at this point. Right now my current targets(If I was to ignore encryption.) are websockets and haste.

Supervisor and FlowM are not only about web, but about flow control. Supervisor is intended as a monad for whatever flow control for trace, testing or whatever purpose for example web navigation. but not only. What is specifically related with web messages is the structure of MFlowState that FlowM has inside.

type WState view m = StateT (MFlowState view) m

type FlowMM view m= Sup (WState view m)

newtype FlowM v m a= FlowM {runFlowM :: FlowMM v m a} deriving (Monad,MonadIO,Functor,MonadState(MFlowState v))

we can think about defining a SMFLowState carried out as a new parameter of MFlow: MFlow state view m a.

But that after decoupling Supervisor and MFlow and make dependent MFlow form Supervisor. For now I would prefer not to do it.

Yes, let's wait until this is done, I wouldn't want to redo the work for the new impl. This seems more important at this point.

About EncriptedCookie, lets go on. make the encripted cookie evident at the type level, and make setCookie and getCookie to encript and decript it transparently. I think that cookies must be ever encripted ever no matter if the session is normal or secure. What about ParanoidEncriptedCookie?

Yes, I'll go ahead and do that then! ParanoidCookie uses 4 different keys to encrypt the 4 different fields.

Here is the def for paranoidCookie:

paranoidEncryptCookie :: Cookie -> IO Cookie paranoidEncryptCookie (a,b,c,d) = do key1 <- getKey "CookieKey1.key" key2 <- getKey "CookieKey2.key" key3 <- getKey "CookieKey3.key" key4 <- getKey "CookieKey4.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key1 iv1 a, encrypt key2 iv2 b, encrypt key3 iv3 c, encryptMaybe key4 iv4 d)

And for encryptedCookie:

encryptCookie :: Cookie -> IO Cookie encryptCookie (a,b,c,d) = do key <- getKey "CookieKey.key" iv1 <- randomIV iv2 <- randomIV iv3 <- randomIV iv4 <- randomIV return ( encrypt key iv1 a, encrypt key iv2 b, encrypt key iv3 c, encryptMaybe key iv4 d)

As you can see, the 1st one uses 4 different keys. It is so that if an attacker manages to break one of the key, he still has to break 3 other ones before he knows what the entire cookie says.

The types would change to:

paranoidEncryptCookie :: Cookie -> IO ParanoidCookie encryptCookie :: Cookie -> IO EncryptedCookie

But otherwise the defs would stay the same.

On Tue, Jan 7, 2014 at 10:36 AM, agocorona < notifications@github.com>

wrote:

it compiles!

Sorry, To do so, I did another commit

2014/1/7 Alberto G. Corona agocorona@gmail.com

So it is a Continuous integration system.. I tried added a travis.yaml with these lines:

language: haskell before_install: cabal install monadloc-pp

let´s see if it compiles....

https://travis-ci.org/agocorona/MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

Using the build system of Heroku, the error is the same, but it can be solved by installing monadloc-pp in the script before building MFlow

2014/1/7 Alberto G. Corona agocorona@gmail.com

What is that?

2014/1/7 Aistis Raulinaitis < notifications@github.com>

Also, take a look at the Travis build: https://travis-ci.org/sheganinans/MFlow

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31727555>

.

Alberto.

Alberto.

Alberto.

Alberto.

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31765163>

.

— Reply to this email directly or view it on GitHub<

https://github.com/agocorona/MFlow/pull/13#issuecomment-31771993>

.

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31781664>

.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31796859> .

Alberto.

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31814290> .

— Reply to this email directly or view it on GitHub< https://github.com/agocorona/MFlow/pull/13#issuecomment-31816942> .

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31886157

.

---

Reply to this email directly or view it on GitHub: https://github.com/agocorona/MFlow/pull/13#issuecomment-31908055

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-31982764 .

[agocorona]

2014/1/7, Aistis Raulinaitis notifications@github.com:

I've decided to close this pull request since there are too many features that have accumulated. I'll be creating some branches and then having a more orderly pull cycle. (Or just switch to Darcs and work in the wonderful world of unordered patches!)

---

Reply to this email directly or view it on GitHub: https://github.com/agocorona/MFlow/pull/13#issuecomment-31723718

I created the MFlow Darcs repository, at the web site, and locally, but the darcs version of windows does not push anything to the web site. It simply freeze. I have to see what happens.

http://hub.darcs.net/agocorona

I have inserted the ACID example as well as other examples in the mflow demo, but I have to test them more. There were a number of them waiting. But that is a bit boring

I also started to code the cloud haskell thing, to make work MFlow servers in parallel, that is more interesting. By the way, this book is very good:

http://chimera.labs.oreilly.com/books/1230000000929/ch14.html#sec_distrib-ping-messages

Alberto.

[sheganinans]

I was able to get mine up with:

darcs get sheganinans@hub.darcs.net:MFlow-Sheganinans cp ../Mflow-Sheganinans.git/* . darcs add --recursive . darcs record (Make sure you have your ssh keys setup. http://hub.darcs.net/#how-do-i-configure-ssh-access And that you are able to login without passing the key explicitly.) darcs push sheganinans@hub.darcs.net:MFlow-Sheganinans

Great to hear that my ACID example is up! Saw your mention on your website! Thank you very much!

Yes, absolutely great book. So good I bought a copy on preorder and now it's on my shelf! That book actually led me to finding a bug in REPA(Reading off of both positive and negative bounds of the array given some circumstances.), which was pretty gratifying. Great to hear that cloud haskell support is coming along! I've been far too busy on-boarding software at work to even look at haskell in the last week! I'll probably be getting around to it later next week(and spare time during the weekend)!

On Sat, Jan 11, 2014 at 2:49 AM, agocorona notifications@github.com wrote:

2014/1/7, Aistis Raulinaitis notifications@github.com:

I've decided to close this pull request since there are too many features that have accumulated. I'll be creating some branches and then having a more orderly pull cycle. (Or just switch to Darcs and work in the wonderful world of unordered patches!)

---

Reply to this email directly or view it on GitHub: https://github.com/agocorona/MFlow/pull/13#issuecomment-31723718

I created the MFlow Darcs repository, at the web site, and locally, but the darcs version of windows does not push anything to the web site. It simply freeze. I have to see what happens.

http://hub.darcs.net/agocorona

I have inserted the ACID example as well as other examples in the mflow demo, but I have to test them more. There were a number of them waiting. But that is a bit boring

I also started to code the cloud haskell thing, to make work MFlow servers in parallel, that is more interesting. By the way, this book is very good:

http://chimera.labs.oreilly.com/books/1230000000929/ch14.html#sec_distrib-ping-messages

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-32092755 .

[agocorona]

Thanks

I had to switch to linux for having cloud haskell running. So I will try the darcs setup in linux , Darcs does not compile in Windows and I suspect that the downloadable executable for windows is too old.

2014/1/11, Aistis Raulinaitis notifications@github.com:

I was able to get mine up with:

darcs get sheganinans@hub.darcs.net:MFlow-Sheganinans cp ../Mflow-Sheganinans.git/* . darcs add --recursive . darcs record (Make sure you have your ssh keys setup. http://hub.darcs.net/#how-do-i-configure-ssh-access And that you are able to login without passing the key explicitly.) darcs push sheganinans@hub.darcs.net:MFlow-Sheganinans

Great to hear that my ACID example is up! Saw your mention on your website! Thank you very much!

Yes, absolutely great book. So good I bought a copy on preorder and now it's on my shelf! That book actually led me to finding a bug in REPA(Reading off of both positive and negative bounds of the array given some circumstances.), which was pretty gratifying. Great to hear that cloud haskell support is coming along! I've been far too busy on-boarding software at work to even look at haskell in the last week! I'll probably be getting around to it later next week(and spare time during the weekend)!

On Sat, Jan 11, 2014 at 2:49 AM, agocorona notifications@github.com wrote:

2014/1/7, Aistis Raulinaitis notifications@github.com:

I've decided to close this pull request since there are too many features that have accumulated. I'll be creating some branches and then having a more orderly pull cycle. (Or just switch to Darcs and work in the wonderful world of unordered patches!)

---

Reply to this email directly or view it on GitHub: https://github.com/agocorona/MFlow/pull/13#issuecomment-31723718

I created the MFlow Darcs repository, at the web site, and locally, but the darcs version of windows does not push anything to the web site. It simply freeze. I have to see what happens.

http://hub.darcs.net/agocorona

I have inserted the ACID example as well as other examples in the mflow demo, but I have to test them more. There were a number of them waiting. But that is a bit boring

I also started to code the cloud haskell thing, to make work MFlow servers in parallel, that is more interesting. By the way, this book is very good:

http://chimera.labs.oreilly.com/books/1230000000929/ch14.html#sec_distrib-ping-messages

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-32092755 .

---

Reply to this email directly or view it on GitHub: https://github.com/agocorona/MFlow/pull/13#issuecomment-32098735

Alberto.

[sheganinans]

Ah yes. The haskell community has always been very linux-centric. Sometimes to the point of letting windows support atrophy. (Plus linux is way better than windows! But it's no lisp machine! TT.TT)

On Tue, Jan 14, 2014 at 4:28 PM, agocorona notifications@github.com wrote:

Thanks

I had to switch to linux for having cloud haskell running. So I will try the darcs setup in linux , Darcs does not compile in Windows and I suspect that the downloadable executable for windows is too old.

2014/1/11, Aistis Raulinaitis notifications@github.com:

I was able to get mine up with:

darcs get sheganinans@hub.darcs.net:MFlow-Sheganinans cp ../Mflow-Sheganinans.git/* . darcs add --recursive . darcs record (Make sure you have your ssh keys setup. http://hub.darcs.net/#how-do-i-configure-ssh-access And that you are able to login without passing the key explicitly.) darcs push sheganinans@hub.darcs.net:MFlow-Sheganinans

Great to hear that my ACID example is up! Saw your mention on your website! Thank you very much!

Yes, absolutely great book. So good I bought a copy on preorder and now it's on my shelf! That book actually led me to finding a bug in REPA(Reading off of both positive and negative bounds of the array given some circumstances.), which was pretty gratifying. Great to hear that cloud haskell support is coming along! I've been far too busy on-boarding software at work to even look at haskell in the last week! I'll probably be getting around to it later next week(and spare time during the weekend)!

On Sat, Jan 11, 2014 at 2:49 AM, agocorona notifications@github.com wrote:

2014/1/7, Aistis Raulinaitis notifications@github.com:

I've decided to close this pull request since there are too many features that have accumulated. I'll be creating some branches and then having a more orderly pull cycle. (Or just switch to Darcs and work in the wonderful world of unordered patches!)

---

Reply to this email directly or view it on GitHub: https://github.com/agocorona/MFlow/pull/13#issuecomment-31723718

I created the MFlow Darcs repository, at the web site, and locally, but the darcs version of windows does not push anything to the web site. It simply freeze. I have to see what happens.

http://hub.darcs.net/agocorona

I have inserted the ACID example as well as other examples in the mflow demo, but I have to test them more. There were a number of them waiting. But that is a bit boring

I also started to code the cloud haskell thing, to make work MFlow servers in parallel, that is more interesting. By the way, this book is very good:

http://chimera.labs.oreilly.com/books/1230000000929/ch14.html#sec_distrib-ping-messages

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-32092755

.

---

Reply to this email directly or view it on GitHub: https://github.com/agocorona/MFlow/pull/13#issuecomment-32098735

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-32323325 .

[agocorona]

By the way, I worked for a few months with an old lisp Machine from Texas Instruments. I was told that the project was abandoned because finally the general purpose RISC processors ran lisp faster than the lisp machine.

One of the problems of the funcitional languages for speed is the abuse of boxed data. It does not have to be that way. I use Leksah, an IDE in Haskell. When I run it in the performance meter of Windows, I observe a lot of page faults, produced in the CPU internal cache due to indirections produced by boxed data. Much more than other processes that occupy more memory and are not programmed in Haskell.

Other functional languages that take the problem of unboxing seriously and try to use more unboxed data structures, like ATS, are more close to the speed of C.

2014/1/15, Aistis Raulinaitis notifications@github.com:

Ah yes. The haskell community has always been very linux-centric. Sometimes to the point of letting windows support atrophy. (Plus linux is way better than windows! But it's no lisp machine! TT.TT)

On Tue, Jan 14, 2014 at 4:28 PM, agocorona notifications@github.com wrote:

Thanks

I had to switch to linux for having cloud haskell running. So I will try the darcs setup in linux , Darcs does not compile in Windows and I suspect that the downloadable executable for windows is too old.

2014/1/11, Aistis Raulinaitis notifications@github.com:

I was able to get mine up with:

darcs get sheganinans@hub.darcs.net:MFlow-Sheganinans cp ../Mflow-Sheganinans.git/* . darcs add --recursive . darcs record (Make sure you have your ssh keys setup. http://hub.darcs.net/#how-do-i-configure-ssh-access And that you are able to login without passing the key explicitly.) darcs push sheganinans@hub.darcs.net:MFlow-Sheganinans

Great to hear that my ACID example is up! Saw your mention on your website! Thank you very much!

Yes, absolutely great book. So good I bought a copy on preorder and now it's on my shelf! That book actually led me to finding a bug in REPA(Reading off of both positive and negative bounds of the array given some circumstances.), which was pretty gratifying. Great to hear that cloud haskell support is coming along! I've been far too busy on-boarding software at work to even look at haskell in the last week! I'll probably be getting around to it later next week(and spare time during the weekend)!

On Sat, Jan 11, 2014 at 2:49 AM, agocorona notifications@github.com wrote:

2014/1/7, Aistis Raulinaitis notifications@github.com:

I've decided to close this pull request since there are too many features that have accumulated. I'll be creating some branches and then having a more orderly pull cycle. (Or just switch to Darcs and work in the wonderful world of unordered patches!)

---

Reply to this email directly or view it on GitHub: https://github.com/agocorona/MFlow/pull/13#issuecomment-31723718

I created the MFlow Darcs repository, at the web site, and locally, but the darcs version of windows does not push anything to the web site. It simply freeze. I have to see what happens.

http://hub.darcs.net/agocorona

I have inserted the ACID example as well as other examples in the mflow demo, but I have to test them more. There were a number of them waiting. But that is a bit boring

I also started to code the cloud haskell thing, to make work MFlow servers in parallel, that is more interesting. By the way, this book is very good:

http://chimera.labs.oreilly.com/books/1230000000929/ch14.html#sec_distrib-ping-messages

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-32092755

.

---

Reply to this email directly or view it on GitHub: https://github.com/agocorona/MFlow/pull/13#issuecomment-32098735

Alberto.

— Reply to this email directly or view it on GitHubhttps://github.com/agocorona/MFlow/pull/13#issuecomment-32323325 .

---

Reply to this email directly or view it on GitHub: https://github.com/agocorona/MFlow/pull/13#issuecomment-32326189

Alberto.