ipfans / echo-session Goto Github PK

View Code? Open in Web Editor NEW

66.0 5.0 36.0 49 KB

Package echo-session is a middleware that provides session support for echo.

License: Apache License 2.0

Go 100.00%

echo-session's Introduction

echo-session

Middleware echo-session is a session support for echo.

This version is working with echo v3. Please checkout v2 branch if you want use session with echo v2.

Installation

go get github.com/ipfans/echo-session

Example

package main

import (
	"github.com/ipfans/echo-session"
	"github.com/labstack/echo"
	"github.com/labstack/echo/middleware"
)

func main() {
	serv := echo.New()
	serv.Use(middleware.Logger())
	serv.Use(middleware.Recover())
	store, err := session.NewRedisStore(32, "tcp", "localhost:6379", "", []byte("secret"))
	if err != nil {
		panic(err)
	}
	serv.Use(session.Sessions("GSESSION", store))
	serv.GET("/", func(ctx echo.Context) error {
		session := session.Default(ctx)
		var count int
		v := session.Get("count")
		if v == nil {
			count = 0
		} else {
			count = v.(int)
			count += 1
		}
		session.Set("count", count)
		session.Save()
		ctx.JSON(200, map[string]interface{}{
			"visit": count,
		})
		return nil
	})
	serv.Start(":8081")
}

License

This project is under Apache v2 License. See the LICENSE file for the full license text.

echo-session's People

Contributors

Stargazers

Watchers

echo-session's Issues

Is it possible to reuse Redis connections from session.NewRedisStore()?

Not sure if this even makes sense or if this is something I would want to do. I don't have much experience with Redis or Go.

Is it be possible to reuse connections made by NewRedisStore()?

store, err := session.NewRedisStore(32, "tcp", "localhost:6379", "", []byte("secret"))

So I could, for example, save data to another database in the same Redis server. When I debug I see that there is a Pool deep down store but I can't seem to access it.

Thanks in advance.

Create branches or tags for echo versions?

Given that echo has changed a lot from v1 to v2, then from v2 to v3 (becoming more like v1), it might be good to tag the last commit to support v1 as "v1", and last commit to support v2 as "v2".

It would be even better (but more work) to create separate branches for each version, and apply any non-version specific changes or fixes to each.

cannot use rs.Writer (type func() http.ResponseWriter) as type http.ResponseWriter

I get the following error:

session.go:67:49: cannot use rs.Writer (type func() http.ResponseWriter) as type http.ResponseWriter in field value:
func() http.ResponseWriter does not implement http.ResponseWriter (missing Header method)

Any suggestions?
I'm using go version go1.10.1 linux/amd64

Handler clearance neglected?

In the gorilla/session description it states:

Important Note: If you aren't using gorilla/mux, you need to wrap your handlers with context.ClearHandler as or else you will leak memory! An easy way to do this is to wrap the top-level mux when calling http.ListenAndServe:
http.ListenAndServe(":8080", context.ClearHandler(http.DefaultServeMux))

Echo is using an own router so I'm wondering if this middleware is already doing that to avoid memory leaks?

Source> http://www.gorillatoolkit.org/pkg/sessions

Cannot get latest version: module contains a go.mod file, so module path should be github.com/ipfans/echo-session/v4

Background

The github.com/Ipfans/echo-session uses Go modules and the current release version is v4. And it’s module path is "github.com/Ipfans/echo-session", instead of "github.com/Ipfans/echo-session/v4". It must comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:

A package that has opted in to modules must include the major version in the import path to import any v2+ modules
To preserve import compatibility, the go command requires that modules with major version v2 or later use a module path with that major version as the final element. For example, version v2.0.0 of example.com/m must instead use module path example.com/m/v2.
https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Steps to Reproduce

GO111MODULE=on, run go get targeting any version >= v4.0.0 of the Ipfans/echo-session:

$ go get github.com/ipfans/[email protected]
go: finding github.com/ipfans/echo-session v4.0.0
go: finding github.com/ipfans/echo-session v4.0.0
go get github.com/ipfans/[email protected]: github.com/ipfans/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v4

Run go get github.com/Ipfans/echo-session, the version will stuck in v3.2.0:

$go get github.com/ipfans/echo-session
go: downloading github.com/ipfans/echo-session v3.2.0+incompatible
go: github.com/ipfans/echo-session upgrade => v3.2.0+incompatible

So anyone using Go modules will not be able to easily use any newer version of Ipfans/echo-session.

Solution

1. Kill the go.mod files, rolling back to GOPATH.

This would push them back to not being managed by Go modules (instead of incorrectly using Go modules).
Ensure compatibility for downstream module-aware projects and module-unaware projects projects

I see these dependencies in your go.mod file, which need modle awareness. So you'd better not use third-party tools(such as: Dep, glide, govendor…).

github.com/labstack/echo/v4 v4.1.6

You also need to update the import path to:

import github.com/labstack/echo/…

2. Fix module path to strictly follow SIV rules.

Patch the go.mod file to declare the module path as github.com/Ipfans/echo-session/v5 as per the specs. And adjust all internal imports.
The downstream projects might be negatively affected in their building if they are module-unaware (Go versions older than 1.9.7 and 1.10.3; Or use third-party dependency management tools, such as: Dep, glide,govendor…).

[*] You can see who will be affected here: [3 module-unaware user, i.e., Soontao/go-simple-api-gateway, xuybin/go-api-gateway, webinone/VCMS-GITHUB]
https://github.com/search?q=github.com%2Fipfans%2Fecho-session+filename%3Avendor.conf+filename%3Avendor.json+filename%3Aglide.toml+filename%3AGodep.toml&type=

If you don't want to break the above repos. This method can provides better backwards-compatibility.
Release a v2 or higher module through the major subdirectory strategy: Create a new v5 subdirectory (github.com/Ipfans/echo-session/v5) and place a new go.mod file in that subdirectory. The module path must end with /v5. Copy or move the code into the v5 subdirectory. Update import statements within the module to also use /v5 (import "github.com/Ipfans/echo-session/v5/…"). Tag the release with v5.x.y.

3. Suggest your downstream module users use hash instead of a version tag.

If the standard rule of go modules conflicts with your development mode. Or not intended to be used as a library and does not make any guarantees about the API. So you can’t comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation.
Regardless, since it's against one of the design choices of Go, it'll be a bit of a hack. Instead of go get github.com/Ipfans/echo-session@version-tag, module users need to use this following way to get the Ipfans/echo-session:
(1) Search for the tag you want (in browser)
(2) Get the commit hash for the tag you want
(3) Run go get github.com/Ipfans/echo-session@commit-hash
(4) Edit the go.mod file to put a comment about which version you actually used
This will make it difficult for module users to get and upgrade Ipfans/echo-session.

[*] You can see who will be affected here: [13 module users, e.g., sasa-nori/nyaitter, elwin/heatmap, gotomsak/fe-learning-back]
https://github.com/search?l=&o=desc&q=github.com%2Fipfans%2Fecho-session+filename%3Ago.mod&s=indexed&type=Code

Summary

You can make a choice to fix DM issues by balancing your own development schedules/mode against the affects on the downstream projects.

For this issue, Solution 2 can maximize your benefits and with minimal impacts to your downstream projects the ecosystem.

References

Can not go get github.com/ipfans/echo-session

Hi.
I get the following error:

[gouser@ec2-goweb ~]$ go get github.com/ipfans/echo-session
go/src/github.com/ipfans/echo-session/redis_store.go:45:46: 
cannot use pool (type *"github.com/garyburd/redigo/redis".Pool) as type *
"github.com/gomodule/redigo/redis".Pool in argument to redistore.NewRediStoreWithPool

on macos high sierra, I get the same error.

Mymacos:~ juliuscaesar$ go get github.com/ipfans/echo-session
# github.com/ipfans/echo-session
go/src/github.com/ipfans/echo-session/redis_store.go:45:46: cannot use pool (type *"github.com/garyburd/redigo/redis".Pool) as type *"github.com/gomodule/redigo/redis".Pool in argument to redistore.NewRediStoreWithPool

Any suggestions?
I'm using go version go1.10.1 linux/amd64

Memory leak with Go 1.7+ even with ClearHandler or context.Clear()

This is a bug gorilla/sessions#122 from upstream. It will be fix in future version of github.com/gorilla/sessions.

It will be fix in new v4.0.0

Invalid code in session.go

Latest commit just broke the entire library:

https://github.com/ipfans/echo-session/blob/master/session.go#L67

Your current head IS NOT compatible with echo v3. There is no Writer() function. Please fix and revert. Your lib is broken now!

CHECK:
https://github.com/labstack/echo/blob/master/response.go#L14

No session set options example

i'm tryng to understand how to set the options for the session (path, maxage etc...) but with no success. Is possible to have an example for this?

Persistent cookie

According to your documentation:

MaxAge=0 means no 'Max-Age' attribute specified.

However, the dependency boj/redistore breaks this ability in the commit referenced here:
boj/redistore@715bb32

This is a basic part of any session service, how do we implement this feature in your package?

Pool type error

I have error on compilation

vendor/github.com/ipfans/echo-session/redis_store.go:45:46: cannot use pool (type *"gitlab.com/intwt/front/vendor/github.com/gomodule/redigo/redis".Pool) as type *"gitlab.com/intwt/front/vendor/github.com/garyburd/redigo/redis".Pool in argument to redistore.NewRediStoreWithPool

... and find this issue - gin-contrib/sessions#61
last release (https://github.com/boj/redistore/releases/tag/v1.2) not compatible, but v.1.2.1 not released

how to solve this problem ?