[go-nuts] Re: mongodb driver for go
We've been using this one in production for quite some time: https://godoc.org/gopkg.in/mgo.v2 Interesting to see the MongoDB folks doing one now too. :) Paul On Friday, 14 December 2018 10:01:09 UTC-8, Badhmanaban M wrote: > > Hi, is there any native mongodb driver for golang > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Go 1.9 introduced error on UDP Multicast JoinGroup
No. I just downloaded and used 1.9 on its release last week. I've
reverted to 1.8.3 for now and, as mentioned, it's working fine for me.
On Sunday, 27 August 2017 16:28:48 UTC-7, Pierre Durand wrote:
>
> Did you test Go 1.9 betas or RCs ?
>
> Le lundi 28 août 2017 01:14:20 UTC+2, oldCoderException a écrit :
>>
>> Hi all,
>>
>> I upgraded to Go 1.9 and since then UDP multicast code that has been
>> running fine for over a year is now failing on JoinGroup. I run this
>> program on linux Mint 18 as root (using sudo), both for the multicast
>> permissions and also to allow listening on TCP port 80 and redirecting to
>> port 443 for SSL. The error returned from JoinGroup is "operation not
>> permitted" which I could expect for a non-privileged user, but not for
>> root.
>>
>> If I recompile the program using Go 1.8.3 the exact same works again.
>>
>> I won't show all the code since there are several structs and "objects"
>> involved, but here's the failing bit, with the interface, listen address,
>> and group address all hard coded just for this example:
>>
>> iFace := "eno1"
>> listenAddr := "0.0.0.0:12080"
>> grpAddress := "224.0.0.12"
>> inetConn, err3 := net.ListenPacket("udp4", listenAddr)
>> if err3 != nil {
>> alertMsg = bsutils.CreateFormattedBSAlert(bsutils.ALERT_CRITICAL,
>> "ListenPacket Failed: %s", err3.Error())
>> return nil, alertMsg
>> }
>>
>> mConn := ipv4.NewPacketConn(inetConn)
>> if err := mConn.JoinGroup(iFace, &net.UDPAddr{IP: grpAddress}); err !=
>> nil {
>> alertMsg = bsutils.CreateFormattedBSAlert(bsutils.ALERT_CRITICAL,
>> "JoinGroup Failed: %s", err.Error())
>> return nil, alertMsg
>> }
>>
>> If it gets past the above code, I then do a SetControlMessage and return
>> mConn for normal serving.
>>
>> thanks,
>> Paul
>>
>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Webservices with Windows Authentication
I can't comment on authenticating a go client against windoze services, but we use both LDAP and Active Directory (AD) extensively and authenticate our users, as well as add and modify them to those services using Go all the time. We use this excellent package: https://godoc.org/gopkg.in/ldap.v2 and use straight LDAP calls both to authenticate against and update AD. All of our Go based web applications allow our users to authenticate against any of multiple LDAP and AD servers in a "federated fashion", trying the servers with the credentials supplied. Hope this helps. cheers, Paul On Saturday, 9 December 2017 14:59:41 UTC-8, snmed wrote: > > Hi all > > We are primarly working in a windows environment and developing web > services as well as web applications. At the moment we're using C# as our > main language, but we consider to > switch to go for the web services. There is one major uncertainty which > hinders us to proceed with our idea, we using Group Managed Service > Accounts to authenticate applications and > services. Therefore we need to handle windows authentication on server and > client side. > > Has anyone a similar use case and has already solved it? Is there a well > documented package which can be used to protect a http.Handler and verify a > user with windows authentication? > And is there a package that can be used to authenticate a go client > against a service which is protected with windows authentication. > > Any help or advise is warmly welcome. > > Cheers > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Update your code if you use golang.org/x/crypto/acme/autocert
I haven't had a chance to delve into this much yet, but for those of us who already have a "redirector" setup on port 80 to redirect ALL non-SSL traffic over to port 443 won't this introduce a problem? Or I suppose we could implement said redirection in the fallback handler, ditching the one we have? regards, Paul On Sunday, 14 January 2018 22:49:39 UTC-8, alex wrote: > > If you use the autocert package, please update your code: you'll want to > add Manager.HTTPHandler[1] call to support "http-01" challenge type. > Unfortunately, this requires listening and accepting requests on port 80 > for the time being. See Manager example. > > Commit which adds "http-01" support to autocert.Manager: > > https://go.googlesource.com/crypto/+/13931e22f9e72ea58bb73048bc752b48c6d4d4ac > > This is due to TLS-SNI challenges being disabled now: > > https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 > > Sorry if this has already been posted. I couldn't find it. > > [1]https://godoc.org/golang.org/x/crypto/acme/autocert#Manager.HTTPHandler > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Modules... why it has to be so painfull?
I certainly agree with everyone who has been saying that implementing modules can be painful. Implementing them was initially a multi-week nightmare of sleepless nights for me, and I still sometimes shake my head with their use. I think that a large part of the problem is that the documentation, which is actually pretty good, is (or was, haven't looked lately) rather bereft of "non-GitHub" and "local, non-domain name" examples. I also think that when you are in the early development stages of a system when there are many library changes taking place, and those libraries all need to be tagged with version numbers each time they change, it just seems a bit much for such early stage development on a system. I can definitely see the benefits, especially if your team is large, and I definitely appreciate them with regards to using open source GitHub modules, but for small teams or single developers with libraries that are in the midst of lots of change, it can be challenging. I didn't see any of the good ideas that I'm seeing in this thread when I changed over, which is unfortunate. Live and learn. I work on Linux and ended up writing scripts to modify the import statements in hundreds of source files, and other scripts that somewhat automate the "go install, git add, git commit, git push, git tag, git push tag" sequence needed for one or all modules. I've also been meaning to look for or write some tool that nicely shows which modules are dependent on which modules, but just haven't had the time. I know they're in each module's go.mod file, but it would be nice to see some kind of big-picture dependency tree or something. It would also be nice to have tools that know which modules are affected by a library module change and just rebuild those when needed. Anyway, it's slowly becoming a part of my standard development practice and is less painful as time goes by. :) -Paul On Friday, 9 April 2021 at 09:01:34 UTC-7 Carla Pfaff wrote: > On Friday, 9 April 2021 at 17:38:12 UTC+2 gonutz wrote: > >> A replace in the go.mod file is of no help here because I still have to >> specify a require with a concrete version or commit hash for the library. >> This means I cannot just change the code in the library module, I also have >> to create a commit and check it in, then go back to my main module and >> udpate not only the replace but also the require in go.mod, every time I >> want to simply place a simple, temporary print statement for debugging >> purposes into the library. >> >> Does anybody have an easy workflow for the common use case? >> > > https://golang.org/doc/modules/managing-dependencies#local_directory > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7f290a9d-f889-4f2f-94f3-4d3e819b5d28n%40googlegroups.com.
