I moved to Bolt 4 (from Bolt 3.7) and would like to implement front-end user to give them access to private contents of the website. Previously, I used the extension BoltAuth/Auth, which worked like a charm.
Now in Bolt 4, there is no easy way like in Bolt 3.x to install an extension from the back-end page. I found out I could use composer to do so, but I run in the following problem:
> composer require "boltauth/auth:3.0.1"
[InvalidArgumentException]
Could not find a matching version of package boltauth/auth. Check the package
spelling, your version constraint and that the package is available in a stability
which matches your minimum-stability (stable).
Either I do something wrong, or the extension is not compatible with Bolt 4.1.
Could someone tell me if there is a way to make this extension work? Or alternatives for front-end user management?
EDIT: I'm now using the bolt/users extension as it can be used to add a ROLE_MEMBERS and let users login for the frontend.
Yes, unfortunately the architecture for plugins (mainly driven by the move from Silex to Symfony) changed completely between 3.x and 4.x and it's not really feasible to release new 4.x compatible versions.
So for now there won't likely be updates to BoltAuth. It may be worth joining the Slack community and seeing if any other developers are working on 4.x compatible solutions to the client login scenarios.
Related
I need to develop one project on hyperledger-fabric using a GO SDK. But as per the latest release GO SDKs that have not yet been officially released.
I had gone through with this post. But still, is it better to use a Go-SDK for any development of the product? So anyone knows it's products or web projects which are in used?
From the chat of the go-sdk-fabric:
fabric-sdk-go is stable. The reason that still in beta just for missing some documentation
The package works but it is kind of a mess, the only documentation are the chainhero example, the test files and the go-doc. There are a lot of package and some of them seems to do the same but they're not always compatible with each other.
I have some Twitter functionality I'm working on and I want to use "Application-Only Authentication" which only needs my Twitter application credentials to just perform GETS in my app (e.g. random tweet searches based on user inputted tags, etc. - no actual user posting.)
Twitter supports this but most of the Twitter packages on Atmosphere and NPM do not. They force you to pass both application credentials and OAuth tokens, if you don't, your requests come back invalid. The most popular Meteor Twitter API package called mrt:twit actually wraps the NPM package ttezel/twit which actually implements Application-Only Authentication correctly, however the wrapper package for Meteor mrt:twit forces you to use Full Authentication requiring the user's OAuth tokens which I don't want or need to use. So I'd like to edit mrt:twit to properly follow ttezel/twit's interface.
However, the mrt:twit package is not on GitHub. How do I figure out where this lives and/or if I can access it locally and modify it and/or find some repository online for where it lives? Atmosphere doesn't offer much help providing no links from where this package is actually downloading?
Link for mrt:twit: https://atmospherejs.com/mrt/twit
Link for ttezel/twit: https://github.com/ttezel/twit
EDIT: I'm using Meteor 1.1.0.2. I was able to find where mrt:twit is locally. It's at:
.../.meteor/local/build/programs/server/packages/
After investigating, it's not that mrt:twit doesn't "implement" ttezel/twit's interface correctly, it's that mrt:twit is using/requiring an old version of ttezel/twit, version 1.1.9 instead of the current 2.1.0. That old version of ttezel/twit doesn't support the "application-only" authorization - I can see it in the code. Hence my above original issue. ttezel/twit downloads to the following folder:
.../.meteor/local/build/programs/server/npm/mrt_twit/node_modules/twit
Inside the above folder I see the full .git package for ttezel/twit but it's version 1.1.9. So I assume I could just replace this folder with the latest 2.1.0 version of ttezel/twit but I don't think you're supposed to have to mess with anything inside of an node_modules folder right? Shouldn't there be a config file somewhere to edit?
For the life of me I can't find where mrt:twit is declaring to use version 1.1.9. In all the code it just calls Npm.require('twit'). There's no config file I can find that sets the version to 1.1.9. The only thing I found is a file at the second path above sitting next to the twit folder called .node_version and all it has in it is v0.10.20 which is a version of Node to use I assume. That wouldn't "force" whatever package versions were out at that time would it? If so, then that's probably what is setting ttezel/twit to use 1.1.9.
My original post question still exists though, where can I find mrt:twit on a server so I can fork it/edit it and not have to edit the code locally?
I emailed the creators of Atmosphere (percolatestudio.com) and Tom was really helpful and pointed me to where mrt:twit lives on GitHub. It's on the old 1.0 atmosphere:
https://old-atmosphere.meteor.com/package/twit
And that page points to the actual GitHub location which is:
https://github.com/subhog/meteor-twit
So the above link is from where the current mrt:twit package downloads into your Meteor app if you add it to your app (as of this writing). Once I found that I could easily see in the package.js file it declares Npm.depends({twit: "1.1.9"}). On a side note: It would be nice if the current version of Atmosphere pointed you to the GitHub location of older/legacy packages how it does the new packages.
So I was able to fork this and update the package to use version 2.1.0 of ttezel/twit. I made a pull request for mrt:twit so hopefully the author updates it - as this is the number one Twitter API package for Meteor with 1,200 downloads. Seemed better to update it than to publish my own version.
Until then, I made a local package following the below link and everything is working great - including application-only authentication. Thanks for the comments - they were helpful. I'm still pretty new at Meteor and how the packaging system works.
http://www.webtempest.com/meteor-js-packages-tutorial
If you want to access the updated package I made it's at the below link but it's not a published meteor package - so you'll have to download it and use it locally:
https://github.com/evolross/meteor-twit
You should check .meteor/local/* folders.
I have a lot of packages files in .meteor/local/build/programs/server/packages
I'm afraid it's all compiled but you can grab some code you need and make your own package.
I've been trying to work through an issue that developed while attempting to upgrade our testing environment from 12.04 to 14.04 ubuntu on aws. Prior to this, the Package repository version of solr was 1.4.1 which matched our 1.4.1 solrj client integrated with our application.
Changing the base AMI to the 14.04 latest and running our default deploy caused solr 3.6.2 server to be installed. It appears it was accepting our configs without issue, however when our client tried to connect we received different errors:
The first was an unknown custom field, which we traced back to our deployment scripts not moving our schema.xml and solrconfig.xml to /etc/solr/conf/ but keeping it in the base directory.
We corrected this issue, and then ran into the following:
'exception: Invalid version or the data in not in 'javabin' format'
This was generated by a wrapper ontop of solrj, but I'll be honest and say I know nothing regarding Solr and that this may be on our end. I've asked our dev team to look at 2 options:
1) enabling: 'server.setParser(new XMLResponseParser());'
Which is the recommendation on the backwards compatibility for an older client.
2) updating our client in the application to 3.6.2
-I know less about the requirements on this.
My fall back is to revert to 1.4.1, but it appears it hasn't been touched since 2011, which makes me hesitant.
Any thoughts / suggestions would be appreciated!
Thanks!
I think the best option is to maintain the same version of Solr and Solrj.
I used for a lot of time Solr 1.4.1 and, while as you said, the most part of it works with newer versions without any problem, actually a lot of things have been changed since 1.4.*
I did your same porting last year, (from 1.4.1 to 3.6.1) and I can confirm you that the 2nd way is the right one: all changes you must do in your client code are just "formal" and very very quick.
Any workaround you could do for being able to communicate with a different version (between Solrj and Solr) is just, as the word says, a "workaround" and it could lead to unexpected (hidden) side-effects later.
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.
What is the recommended way to deploy Node.js on Ubuntu 12.04 in a production environment?
I saw this ppa but I don't know if is well maintained or if it will and if is a source in witch one can trust.
I know that is easy install Node.js manually, but seem to me that install it using the Ubuntu packages manager will allow me safe some management time and will be more integrated with the way the underlying server is being currently management. So, what are your recommendations? Thanks in advanced.
we are using Chef with the existing node.js cookbook
Well, after read lot of posts and pages that talk about Node.js deployment-installation, I must said that Chris PPA is mentioned in tons of them as an official source. Beside one can see her PPA linked at the Github Node.js wiki.
So, seem to me that is trust enough to be used in production, what made it the choice if you want keep your system updated using standards Ubuntu tools.