It's too long for MongoExplorer. For some reason MongoExplorer set the maximum password length to 20. The one generated by mvc tunnel doesn't work.
I'm afraid you can't as this is actually the credentials generated for your service (not only for the tunnel feature). Maybe you can pass the password to MongoExplorer in another way (maybe command line argument?)
I'm afraid the password is generated so you cannot change it. I would raise a defect/bug against MongoExplorer (I just checked, and the site says that development is currently suspended). FWIW on the Mac I use MongoHub as a GUI, and that works fine with a vmc tunnel.
Related
I am trying to figure out how to get monitoring to work in Postman.
I have written tests on the desktop client for get/create/put and everything works fine. I'm using a localhost address and port 5004 which is the port for the API.
http://127.0.0.1:5004/bookings
I have tried to change the proxy in setting to localhost and port 5004, I have tried to change it to 127.0.0.1:5004, I have tried to disable SSL on the desktop client. I am running the monitoring on using the desktop client from the browser, that doesn't work either.
I have also checked if my etc/host file contains 127.0.0.1 localhost and it does.
Not sure what else I can try, I would appreciate any help. :)
Accessible APIs:
Monitors require all URLs to be publicly available on the internet as
they run in the Postman cloud. A monitor cannot directly access your
localhost or run requests behind a firewall. However, to overcome this
issue, static IPs are available on Postman Business and Enterprise
plans.
https://learning.postman.com/docs/designing-and-developing-your-api/monitoring-your-api/intro-monitors/
you cannot use the monitor for inhouse and localhost websites, You could upgrade to enterprise or business plans and see if that helps
The issue is maybe you configured the environment variable and passed the correct value in the URL also
But while running the collection test class
didn't select the correct environment
Select the environment configured to run that collection, shown in attached screenshot
I faced this problem and the issue was my DNS address. After changing the DNS server it was solved.
I had the same problem, I had space between ip and :port =>0.0.0.0b:1111 in my env. I deleted the space and I can connect. => 0.0.0.0:1111.
I faced the same issue and it got solved by removing the env variable
what you should try is sign out, sign in again. make sure the environment variables are not empty.
also, try using the feature console.log(get environment variable name) it would be helpful.
make sure to click on persist all in the environment variable.
The key for me was to click on "persist all" in the environment variable
read the github
some comments which helped me resolve the issue
In my next.js project,I want to set cookies when user logs in. with document.cookies(something) it is setting cookies, but it is limiting to set only one cookie. If I give more than one cookie it is taking only the first element. In both cases I am not able to get cookie values in the pages.It is giving document is not defined error.I tried using
https://github.com/js-cookie/js-cookie,
with this I am able to set and get cookies,I am not able to secure my cookies. It will be great if you can solve this or suggest me some methods.
Thanks in advance.
I'd suggest using https://www.npmjs.com/package/nookies as it's kinda tricky to do manually.
You can't use the secure flag when your app is running on localhost unless you are running the application on https. To test if the secure flag is working, deploy the application on production or testing environment.
We have been implementing GREG5.0 and using default configurations everything works fine. Once we replace the default localhost certificate in the wso2cabon.jks keystore with our own we receive "java.security.SignatureException: Signature length not correct: got 256 but was expecting 128" when we log into Store or Publisher using SSO.
We have removed the default keypair from wso2carbon.jks and added our own certificate. The password for our keystore and certificate are the same. We have updated all the configuration files per the wso2 carbon 4.4 documentation. We have updated JavaHome with local_policy.jar and us_export_policy.jar in order to allow for the longer key length.
The administrator console works great with no issues. If we change the login method of store or publisher to "basic" then it works fine. When we have the login method set to "SSO" we end up sitting on a blank page at this location https://servername/store/acs. We have the same result in the browser if we are running as a windows server or in console mode but, if we are running as a windows service then we have no error and no indication of what happened. If we are running in console mode then I get the error mentioned above spit out in the console.
I also noticed this behavior on Identity Server 5.0 when accessing dashboard.
We are running on windows.
Is there another location in WSO2 that I need to update to accomodate an increased key length?
Joe
The location I missed updating was the IdentityAlias in repository/deployment/server/jaggeryapps/store/config/store.json repository/deployment/server/jaggeryapps/publisher/config/publisher.json. Once I updated that value to match the alias of the keypair I was using in wso2carbon.jks that appeared as though it solved the keylength error and created another problem.
So now it was giving me a NullPointerException. I had provided the alias of our keypair but that was not the same as the alias for our certificate exported from our keypair that we loaded in client-truststore.jks. So I decided to set both alias' so they would match. With that change I was finally able to successfully able to access the store and publisher.
After some further testing it did not care what my keypair alias was as long as the value in IdentityAlias matched the alias of my certificate loaded in client-truststore.jks.
Hope this helps someone.
Joe
The AWS command line tools appear to be broken on both Linux (Ubuntu PP) and Windows (7). In both cases, after setting up the login credentials correctly and trying to run the most basic tool (getBalance.sh), I get a failure to authenticate.
An error occurred while fetching your balance: This request must be made over a secure channel. You must use 'https' rather than 'http'.
Seems simple enough, but there's nothing in the manual nor in the installed directory which would suggest that this is an option supported by the command line tools.
Has someone already modified the shell scripts to use a secured connection? If not, any clues as to where I should begin the modifications?
I haven't used the tools extensively so can't say this solution is extensively tested but getBalance.sh worked after doing this
See this thread:
https://forums.aws.amazon.com/message.jspa?messageID=333485
From the link:
Edit the Command Line Tools Installation Directory\bin\mturk.properties file and edit the service_url to use https instead of http – i.e. https://mechanicalturk.amazonaws.com/?Service=AWSMechanicalTurkRequester for production, and https://mechanicalturk.sandbox.amazonaws.com/?Service=AWSMechanicalTurkRequester for sandbox.
I'm trying to implement Facebook Connect on a website with .NET MVC using C#.
I've followed the instructions here: http://wiki.developers.facebook.com/index.php/Trying_Out_Facebook_Connect step by step. I can make the login work as in that when I log in through the site I'm also logged into Facebook.
In order to work with this in the server I think I need to access the cookies Facebook is supposed to leave like:
APIKEY_user
APIKEY_session_key
...
as mentioned here http://wiki.developers.facebook.com/index.php/Verifying_The_Signature.
The thing is I'm not getting any of these cookies. I've googled and it seems like I'm the only person with this problem. Any ideas as to what I could be doing wrong ? Has this happened to anyone else ?
The issue was that I was developing locally using localhost.
I resolved the problem by changing the settings for the application to point to a certain web address instead of localhost and changing my hosts file lo point that same web address to 127.0.0.1
from the UI/client-side perspective, always insure you have the correct path indicated for the xd_receiver file in your FB.init() method.
Firecookie is very useful for seeing what Cookies are/aren't being set.