I need to create a token in TESTNET. I launched the Waves client but i cannot see any option to switch to TESTNET Network. Is there a way to configure WAVES client so i can create or use wallets in TESTNET and then create tokens, try leasing etc?
yes sure, just go to this link https://testnet.wavesplatform.com
then you can use Waves Client on testnet.
Related
So I'm starting to use Redis and Socket.io to broadcast events to the client side. I'm using Laravel for the backend and will take advantage of their event functionality.
Based on a user's access level, I only want them to listen to certain channels. I figured I could dynamically set the channels they will listen to, but I was worried about whether or not they could use a debugging tool or the sort to change the channel they're listening to.
For example, maybe the page will load listening on 'channel-100', but can they alter the code so that it can listen to any other channel, like to 'channel-110'?
I am not sure I can help specifically with Socket.io, but I can tell you how we have approached that in our realtime system, and this may apply to your problem.
Clients can request to attach to a channel, so it's the inverse of what you suggested i.e. clients decide what they listen to, server's don't decide. See how channels attach.
Now to address your concern of which clients can access which channels then, your Laravel app should be issuing a token that specifies what rights it has. As your Laravel app is responsible for identity management and knows who the user is, it is always best positioned to have this up to date information at any time. So your client should request a token from your Laravel app, which is passed to your Socket.io server, which should in turn then apply rules to allow / disallow requests to join those channels. That way your Socket.io server does not need to have any business logic embedded from your system, and issuing tokens is easy in your app.
See how we made token authentication can work with your app.
I realise it's not a direct answer, but I hope it helps how you think about it architecturally.
Matt, co-founder, Ably: simply better realtime
I have a web application using XMPP for chatting. The only real problem is that users have to create their own XMPP account on the right server. I'd like to automate this process.
How do I automatically create a new XMPP account for a new user ? How do I know what address can be used or not for the account ?
There are a few different approaches:
Have the client register in-band. They can then choose their username themselves.
Connect to an existing user database, or interface with it directly.
The server might have some CLI or Web-based management tool that can be used.
As ggozad wrote, use the Add user command defined by Service Administration.
You need to implement (and your server to support) XEP-0133 Service Administration and in particular the add user command. You can create random user ids or generate them with some logic and store them somehow to check for uniqueness. The get-registered-users command might also be of help.
We're looking to use the UDID to authenticate a user against server-side web services for an iOS application. My one concern is that users will try to brute force access to another user's account by making auth attempts using random UDID values. I can work on things such as throttling their requests, however I was curious if there is a way to make a "signed" request.
Meaning, is there a way I can certify that the client with UDID foo was generated and sent from the device that UDID foo belongs to, and not some random user with access to curl and a ruby script to call my service multiple times?
I think what I'm looking for is a signed http request. I'm not sure where to start building out such support on either the client or server though.
Those GUIDs are huge. The chance of guessing one seems extremely remote. I'd guess it would take several millennia to come across one 'randomly'.
You are almost surely at more risk of someone sniffing an existing one or using their access to the user's device to obtain it.
Honestly, given how easy it would be to obtain a user's udid, I'd be surprised if Apple didn't recommend against using it that way.
All it takes is for me to email one of your users with a link to my "cool new free game" and bam I've got the udid.
Or, sitting in a coffee shop, and sniffing WiFi traffic - waiting for some ad-sponsored game to send the udid over the wireless for tracking purposes.
But...
How about Client SSL Certificates?
How to use Client Certificate Authentication in iOS App
Or Signed XML Documents?
http://en.wikipedia.org/wiki/XML_Signature
Honestly, there is only so much you can do in this regard.
You'll never be able to stop a truly determined bad guy from cracking open your .ipa and extracting a client side ssl cert - or whatever other mechanism you have to thwart someone.
I'm just saying - since you are distributing the application (this isn't an in-house application running point-to-point over the internet) there is really no way to truly secure the client (mobile) side code - and thus, no way to truly ensure only authorized clients are making requests to your service.
Ultimately, the burden of security is on your services.
You should give a try to HTTP authentication
I am looking for some suggestions on how to secure access to a RESTful API which initially be used by an iPhone application, but will have other clients in the future. The data exposed by this API must be kept secure as it may contain health information. All access will be done over HTTPS.
I was thinking that I'd like to require pre-registration of the iphones at setup and then also some type of PIN/Password on each request. So, simply knowing the password without pre-registering the phone/client won't provide access. I was thinking about somehow tying it to the iPhone identifier if that is possible, but not sure it would provide any additional security. The iPhone identifier is just another piece of information and it may not even be that secret.
So, some requirements would be:
Use some type of pin-based solution on the iPhone, but want more security then a simple 4-6 digit pin can provide.
No passwords could be sent in the clear.
Not be subject to reply attacks
Having to pre-exchange some data between client and server when setting up client is OK.
I would think that, if the application contains medical records, you would want to have the user authenticate every time they use the application or, at least, have some way of pushing down a disable message that renders the app useless in the case where it is lost or stolen. The 4-6 character password (pin) would also concern me with respect to HIPAA, if it applies.
You might want to treat it as a standard web app from the server perspective and do session-based authentication and access with a session that times out, perhaps after a long period, and re-authentication on timeout.
You could use SSL with client authentication. If a device gets lost, you can remove the certificate on the server. There are some obstacles though:
It is not entirely clear if/how you can do client authenticated SSL on the iPhone Unfortunately, there is not much documentation about it. Have a look at Certificate, Key, and Trust Services Reference
You have to create a private key for every device
You also have to figure out a secure way to transfer the private key to the device
I am building a iPhone web based app for our execs to view sales data. The app goes over SSL with a typical login page that sets a cookie for the day.
Since the info is sensitive and we have a VPN at work I was hoping as a double precaution I could send all communications with this app over our VPN.
Is there a way I can route traffic over the VPN only for a specific URL? Does anyone have any more info on the "Send All Traffic" in the VPN configuration
Thanks
The app has very little control over the VPN. A properly configured HTTPS site (particularly employing bi-directional certificates) will give you the kind of protection you're looking for your application.
That said, I strongly advocate that business users send all data over the VPN in all cases. This eliminates a wide variety of attacks and provides the opportunity for additional monitoring and protection. Thus, I generally recommend using the "Send All Traffic" VPN configuration. This would allow you to move the app entirely internal, so that outsiders cannot access the login page.
Properly done HTTPS should be sufficient. Provision the phone with a client certificate (there's a tool for that) and ensure the server checks them... and use a revocation list on the server side in case of stolen phones.
Making settings and managing the VPN routers and servers in iPhone is not easy. You should to make some HTTPS settings for this. After this, the client will be able to access your computer. Otherwise iphone vpn will lose its goal to run the server.