Soooo for some reasons, i had to change my system date to a future date (2018). Now, everytime i try to open the Controller (just with Controller, not VuGen or Analysis) i get the message bellow. I tried re-installing the Loadrunner, but it seems that it keeps taking the future year since i'm still getting that message.
My version is Loadrunner Community 12.5.
I would like to know a way to change back the date to the present or how to do a clean unsintall, whatever it takes to make the controller work again.
Here is the error msg
Wipe the OS or Call support (which requires a paid contract). For obvious reasons the license manager is pretty tight because people have tried all sorts of things over the years to circumvent an expiring license. You have likely been trapped by code which checks for such behavior and unfortunately to disclose how to address this would also likely disclose how to defeat aspects of the license manager for unscrupulous individuals
Related
In the past, I've been using the Delicious API available under feeds.delicious.com. When running this code today, I found out that the corresponding hostname is not available any longer (checked first time some days ago). I've already asked Delicious support directly about the state of the API, but not yet received an answer. So I thought anybody here might have more recent information, whether this is some temporary outage or the API has been cut completely?
This was likely part of the rollback to Delicious's old architecture in January 2016:
Fortunately for us, the version that the javascript site replaced has been kept alive at previous.delicious.com. This was built using a much more traditional framework, and it’s great! In fact, many of our longtime users have continued to prefer it over the main site, and frankly, so do we. Therefore, we are switching to this platform for our main site, and this transition will position us to quickly iterate in our ongoing efforts to keep Delicious thriving.
The auth URL on the documentation's OAuth page (delicious.com/auth/authorize) 404's for me as well, so I have a feeling this has indeed been retired.
I am sick of the absolute pile of rubbish that is the paypal sandbox for numerous reasons but one thing that is annoying me especially at the moment is the login cookie length. It lasts all of 5 minutes before you have to log in again. You lose the page you were on and end up back at the dashboard after punching in your password for the 500th time that day.
I am testing reference transactions (another completely embarassing sandbox implementation) and whenever I go to check or change something in the account I am using to pay I am logged out.
Is there any way to force it to keep me logged in for longer?
if you are logging into another account to pay, this is why you are being logged out. try using another browser, or private browsing to keep your logins separate.
I work with the sandbox every day and I don't have any issues in general. Not sure why you would be talking so badly about it.
The session thing is something PayPal does (like any financial website) to protect people. Yes, it's the sandbox, but it's meant to simulate the live PayPal site, so that session will act the same.
As for your comments about reference transactions, I guess you'll need to expand on that. I've thoroughly tested reference transactions in the sandbox for numerous projects and have never had any issues with it.
One thing I could recommend that would help with typing in the password over and over (as well as help you maintain good password standard practices in general) is to use LastPass. You'll never have to type a password again.
Another option would be to setup a local solution using the TransactionSearch and GetTransactionDetails APIs. For example, I've started something like that with my PayPal Glass project, which is essentially replicating the PayPal interface with my PHP class library. Notice that I don't have any sign in protection on that at all, so it never times out or anything.
It's a little more effort up front, but you can save lots of time in the future with projects like you're working on. If you're working with PHP you could grab that PayPal Glass project from GitHub and just use it with your own sandbox.
I can't use Chargify, Recurly, Spreedly or any of those apps because I am not based in the US. I am in Jamaica, actually...so many of these companies don't support Jamaica.
But I am trying to roll a custom subscription management solution - but given that this is my first web app - I think it might be too big a task for me to take on.
Are there any gems that can handle this? These are the requirements:
All users registered automatically get on a free plan for X days
Towards the end of X days, they should be prompted to upgrade
If they don't upgrade, at the end of X days their account gets locked/disabled
If their account is disabled, they can upgrade and be taken to a checkout page (powered by 2checkout, because that is who I have to use for now).
Then once they upgrade, and have selected a plan, the system should automatically increase their allocations (# of clients, # of projects, storage space, etc.)
So I don't need the system to actually handle the processing of the credit cards, etc. It's more the logic of the subscription, restrictions on the models, upgrading and downgrading that I need.
The perfect solution would be a well supported Rails gem that I can include in my Gemfile.
If you don't have that, just send any/all possible solutions and I can take it from there.
Thanks.
You can look into Saasy. It's a stand alone Rails app (not a plugin) that you host on a subdomain and communicate with it using SSO/REST protocols. Probably won't fit your need as it is, but you may be able to extend it or get a general idea of how it works.
There is a great solution called Chargify, its one of Heroku available add-ons, you can see it here: https://addons.heroku.com/chargify and http://devcenter.heroku.com/articles/chargify
With a reasonable rate, you can manage all the recurring/subscription billing in your Rails App, I hope this is useful answer.
I have developed a small software. I want to provide and run it commercially only. I want it to be run in the machines who have purchased it from me.
If someone copies it from my clients computer and runs it in next computer, I would like to stop functioning/running the software.
What can be the ways to prevent the piracy of my software?
Adaption of one of my previous answers:
There are a few ways to "activate" copied software to try to stop casual copying of the application.
In the most simplistic case, a registration code ("CD key") purchased from you, possibly via your website, and it is sent to the user who enters it into the program or installer. The whole process can basically be done offline; the program itself locally determines that the code is valid or invalid.
This is nice and easy, but it extremely vulnerable to key sharing - since there's no "phoning home" then the application cannot know that thousands of different people are all using the same key that they got off the internet or a serial library or their friend. It's also reasonably easy to make "keygens" which generate valid-seeming keys that were never actually issued by the developers.
Then we get into online registration. You still have some kind of code, but the program will phone home back to the server to determine whether the code is valid and usually unique. This stops basic key sharing, because the company knows if too many people from all over the world are all using the same key. Perhaps there is some kind of identification involved using MAC address, too, with infinite registrations allowed on the same hardware but maybe a limited number on what appears to be a different computer.
This is still pretty easy and stops simple key sharing. People will actually have to get into cracking the software or faking the server response to get past it.
Sometimes the program itself is partially/mostly encrypted and is only decrypted by the online registration step. Depending on how well this is obfuscated then it can be pretty difficult and time consuming to crack. Bioshock was a high-profile example of this - debuting with a brand new encryption/copy protection scheme that took around two weeks from release to be broken.
Finally, a particularly guarded application might stay in constant contact with the server, refusing to work at all if the connection is severed.
If you know for sure that all your users will all have reliable internet connections then it can be considered quite a strong way to protect the app, at the cost of privacy and some user distrust of the spyware.
In this case to get around the activation they would need to fake the server itself. Steam emulators and private WoW servers are an example of this.
And in the end, nothing is uncrackable.
In a nutshell: you can't.
Even very sofisticated systems (e.g. dongle keys) can be circumvented.
I guess your best call is to give a code to your customers and have an online check for that code, so that it cannot be used twice.
Of course, that can be circumvented too but...
As nico said you really can't.
A simple solution might be to generate (registration/activation) codes that are based on hardware or software installed on the particular computer - eg video card serial id or c:/windows creation time.
I have one idea may be it works.
What we can do, we will make an encorrupted database field and that field will be empty for the first time as soon as i install my software to some machine it will read the Mac Address + Mother Board Serial + Processor ID and make an encorrupted value with the combination of these three and write in to that field which i left empty for the first time use.
After that every time my application will read these three values and recreate the encrupptted value in the same manner and compare with the value of that database field. If the value of the database field and the value of the regenerated encrroupted field is equal, that means the computer is same other wise it is installed on some other machine in this case you delete all the code and can make the system unstable to punish the person also :) ...
Please let me know about your opinion about this idea.
The best way is to use some sort of hardware-locking in which your license code contains encrypted info about the machine on which it will run. Your software will then check for this info and match it with the current computer and if the match is successful, the license is deemed valid.
Sure, any scheme can be cracked by someone on the face of the planet, but that does not mean you shouldn't use a protection scheme.
If you are looking for a ready-made scheme for this, have a look at CryptoLicensing.
Companies such as ours (Wibu-Systems), Safe-Net, and Flexera (expensive) offer dongle-free solutions as well as ones based on hardware. But _simon was right in that a dongle is the only iron-clad protection. All software-based systems can be cracked; it's just that some are more difficult than others. Really good hardware-based solutions are effectively uncrackable. No one has yet cracked the CodeMeter stick unless the implementation was flawed.
I have a little experience with bug tracking systems such as FogBugz where help tickets are issues are (or can be) bugs, and I have some experience using a bug tracking system internally completely separate from a help center system.
My question is, in a company with an existing (home-grown) help center system where replacing it is not an option, how should a bug tracking system (probably Mantis) be integrated into the process?
Right now help tickets get put in for issues, questions, etc and they get assigned to the appropriate person (PC Tech, Help Desk staff, or if it's an application issue they can't solve in the help desk it gets assigned to a developer). A user can put a request for small modifications or fixes to an application in a help ticket and the developer it gets assigned to will make the change at some point, apply their time to that ticket, and then close the ticket when it goes to production.
We don't currently have a bug tracking system, so I'm looking into the best way to integrate one. Should we just take the help tickets and put it into the bug tracking system if it's a bug (or issue or feature request) and then close the ticket if it's not an emergency fix? We probably don't want to expose the bug tracking system to anyone else as they wouldn't know what to put in the help center system and what to put in the bug tracker... right?
Any thoughts? Suggestions? Tips? Advice? To-dos? Not to-dos? etc...
Have a promote to bug button on the help desk system, that publish the ticket on the bug tracker, with the appropiate reference info.
Is this for a production system with end users reporting bugs, or for issue resolution during QA?
If it is the former, some live person should triage the help desk tickets and only log as a bug what really is one.
If it is the latter, you should not integrate at all.
Well, it's a tradeoff.
We use separate systems for help desk tickets and for bugs.
Pros:
Workflows & requirements will probably different between devs and help desk, you can choose a system for each that fits requirements (e.g. fields that are only relevant for dev or for help desk, different kinds of email integration).
Clear responsibilities: Help desk handles tickets, devs handle Bugs.
Cons:
Integration will not be quite seamless (you need either automatic integration, which does not always exist, or manual back-forth links, which people may forget).
So far, we're quite happy with two products. It is occasionally annoying to have to paste links or close a ticket and a bug, but usually tickets and bugs are handled by different people anyway, so it's not a big deal.
One product might also work well, if you can find one which fits everyone's workflow.
In the raiseaticket help-desk system, we create a separate workflow for Prod, Dev and Bugs. The ticket is assigned to relevant group based on the nature of the issue. These tickets are not exposed to any other group. So, we can do a workaround in our help-desk portal system for the bug tracking.
For anyone in 2022 (and beyond) looking to integrate a help desk system and bug tracker, DoneDone does this well.
We use a DoneDone mailbox for general customer support (both via our support email address and the contact form on our website). It lets you have private discussion on emails, along with allowing you to assign, prioritize, tag, and create/change statuses on them (e.g. "Open", "In Progress", etc.)
We use DoneDone projects to manage internal bugs/issues/tasks.
DoneDone lets you connect support emails (the helpdesk part) to internal tasks (the bug tracking part) as well. So, if your company has distinct support and client-facing people while also having internal devs and you want to separate their work, you can create any number of subtasks from an incoming conversation.
Even if your company isn't that stratified, it's nice to be able to create bugs with their own workflows separate from a helpdesk ticket (which has its own workflow).
More info at https://www.donedone.com