Which Nitrogen handlers have you customized?

[Jesse Gumm]

Hey Nitrogen folks (Nitrogenes? I feel like we should have a term - "Nitrogeners" sounds dumb to me).

Anyway, I was just curious, given Nitrogen's handlers, which handlers you've gone through the efforts of customizing, if you have at all.

The handler system could use a bit of an overhaul, and some of them feel like they should either be reworked heavily or removed.

Right now, my plan is to remove the log handler and the config handler. Given the OTP team's introduction of logger with its own handler system, it seems unnecessary for Nitrogen to have a log handler at all.  

Similarly, I'm inclined to rework and/or combine the session, role, and/or identity handlers (not sure yet).

And the query handler needs work to allow disambiguating GET variables vs POST variables.  It's something that can be done with a custom query handler.

So my question for the community is: which handlers have you customized, and in what ways?  I want to make sure I'm not breaking functionality you rely on, and if there's a common thread, perhaps it makes sense to add that functionality to nitrogen_core.

Thanks in advance for your responses!

--

Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

[braun...@gmail.com]

I have customized the dynamic route handler. The one which looks up modules in the hard disk... I took the original source code and altered here and there to get the page elements from the app/0 function instead of main/0, basically. I dont think a rework of the handler would have made any change for my use case, so I just forked it.

Another one I read a bit was the state, session handlers. It turned out to be too complexy for my needs so I just use some cool functions around ETS, because the handler itself does some redundant initialization everytime you access it. I'm actually considering getting rid of the wf:user and wf:role too. The wf:user can just be stored with wf:session, nothing more. And the wf:role I want to succeed with a storage abstraction which provides sets, ETS does this naturally.

Another thing I dont like is wf:session storage dissapearing after the server goes down. There should be a variant which goes to mnesia, for example: wf:permanent_session.

The session storage is a better option than using cookies, but the need for keeping the data for a long time, if needed, is the same. Imagine losing all logged in clients data just because
the server goes down for maintenance (or even a crash)

This is the current storage primitives Im using instead of plain wf:state/wf:session, maybe u can get the patterns which I feel are needed for a SPA:

http://linkode.org/#PWKJYQ2D1oMl6PmQOTJlM3

And the route handler im using now too:

http://linkode.org/#xQBfHLG5KRa4C0hu0xWvJ4

[Bunny Lushington]

On Dec 1, 2020, at 19:50, Jesse Gumm <gu...@sigma-star.com> wrote:

Hi Jesse &al. —

Hey Nitrogen folks (Nitrogenes? I feel like we should have a term - "Nitrogeners" sounds dumb to me).

I’m stumped.

Anyway, I was just curious, given Nitrogen's handlers, which handlers you've gone through the efforts of customizing, if you have at all.

I regularly use modified handlers.  Here's a rundown:

config_handler: I've updated get_values/4 to use my application name

(?APP, defined by a modified -include().  I did this years ago but now

forget exactly why.  (If I had to guess, I'd say it had something to

do with modifying to build with rebar3.)

role_handler: Modified to query a database backend.  I think I added

this to ensure that role as checked on each request and not ever

relying on a cache.

query_handler: Added a call in set_websocket_params/3 to reset a

session timer.

security_handler: Added a call in init/2 to create or update a session

timer.  Also added a means to redirect to a login page for all pages,

even those usually publically available.  (I use this for

demonstration and testing instances.)

route_handler: Added code to detect, auth/authz, and route API calls.

A quick word on my session timer: for each (authenticated) request a

process is started or restarted with a timeout. The process state

contains the most recent wf:context and is able to push a "you will

timeout in one minute..." modal or actually log the user out and

redirect to the login page.

Speaking off the cuff from a remembered pain point: if there was one

item on my wishlist it would be a way of implementing a handler (even

the existing security handler) for websocket requests.  In the default

case the request could just pass through to the appropriate event/1

but it could also be hijacked for other processing.

b.

[Anton Prokofiev]

Hello, Jesse,

I am customizing

config_handler - as was mentioned before: to read parameters from application config file.

security_handler - handle login/logout mainly check that session is not expired yet.

Regards, Anton

[Jesse Gumm]

Everyone,

Thank you so much for your responses so far!  I really appreciate it.

If anyone else has modified their handlers, feel free to continue.

This is great feedback, and gives me some stuff to chew on.

-Jesse

--
You received this message because you are subscribed to the Google Groups "Nitrogen Project / The Nitrogen Web Framework for Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nitrogenweb...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nitrogenweb/86662a9e-0872-42e7-8dec-e155ae9f3f29n%40googlegroups.com.

[ramkrishn...@gmail.com]

Hi Jesse,

I'm a bit late on this but thought I'd let you know that I've customised session handler so that session information is encrypted and stored in a cookie on the client side. 

I've done this to make the session work in a load balanced, auto scaling, clustered environment. 

Thanks.

[braun...@gmail.com]

Do u have that code open sourced? You now do wf:session(...) and session data goes to the client? Thats what you're doing? The default handler loses that data after reboots. I also have been thinking about putting that data on the client. It survives after reboot and it doesnt need to be in the server, really. How are you encrypting the data?

[Ramkrishna Kulkarni]

Hello,

It's simply an extension of simple_session_handler.erl which already does the encryption (pickle, depickle) of the session cookie. I've added a list to the record to save session values in the cookie and stripped out process registry code. Note that this cookie should not bloat up else it'll lead to performance issues.

Please check here: https://gist.github.com/rkulkarni/948696a0b5c0920170e073c12919cfd9

Thanks.

You received this message because you are subscribed to a topic in the Google Groups "Nitrogen Project / The Nitrogen Web Framework for Erlang" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nitrogenweb/AH6H2Pj3Xvs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nitrogenweb...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nitrogenweb/c08f3901-bf27-42e7-b60e-ce662fb215acn%40googlegroups.com.