Jump to content

Sasun Steinbeck

Resident
  • Posts

    254
  • Joined

  • Last visited

Everything posted by Sasun Steinbeck

  1. Thank you this is all good food for thought! In the end it all comes down to how the tools are actually being used in the end and if anyone finds that useage objectionable enough to file an AR.
  2. I designed the RFL raffle boards. This raffle board is essentially the same thing but will be sold as a commercial product. So obviously they are allowed for RFL but I wasn't involved in any discussions with LL about how to make them OK by the rules or whether RFL was given some kind of special exception - I have no idea. Those raffle boards give out a token item with every ticket purchase. But there's still a main prize to win at the end of the raffle. But the language everywhere is clear... the money is going to a legit charity. This is exactly the direction I want to head with these. I'm just wondering where the line is between what is not acceptable and what is. How does the language of a charitable donation for a ticket vs. non-charitable make it legal? Or the fact that you get something for every ticket purchase AND have a chance to win a prize? One of the existing commercial raffle boards gives you the first ticket free. This, by their instructions, makes it legal. I just don't see how that gets around the rules, myself. Doesn't the purchase of the 2nd ticket mean it's gambling?
  3. Policy reference: https://wiki.secondlife.com/wiki/Linden_Lab_Official:Policy_Regarding_Wagering_in_Second_Life I would like to bring to market a raffle board, primarily for people doing fundraisers. I see a zillion raffle boards for sale in the marketplace, they are clearly not banned there, at least. But I'd like to provide some guidance to customers on what might get them into trouble with the raffle board. These are not promotional (free) raffle boards - you pay money, random chance determines one or more winners of the prize. The prize is determined by the raffle board owner and could be anything. Seems obvious that offering $L as the prize puts the raffle board squarely into "gambling" category and should never be done. The policy says that if the object in question "in any way risks Linden dollars based on whether an event may or may not occur" then it is considered gambling. One could argue that with a charitable fundraiser, there is no "risk" of losing $L, since it should be common sense that your donation is 100% guaranteed to be gone from your account and not coming back and you know there is no cash prize. Where's the "risk" here? They also say "If the 'payout' involves objects that are more akin to novelty objects that cannot readily be converted into Linden dollars, real-world currency or value, then that activity will likely be permitted." So... if you are not giving out cash, you could argue that selling your prize (if if it's even worth anything and is Xfer OK) in a store/marketplace somewhere (and hoping that someone even buys it) is FAR from being "readily converted". It's not like you can just go cash in your random prize object anywhere. I realize that in the end it would require someone to abuse report your raffle board and a Linden would have to say yes or no in specific cases. So anything I would say would be in the form of opinions and guidelines, or better yet as my own policy on allowed use of the raffle board. What do you think?
  4. I'm guessing that as soon as you get off the vehicle your PERMISSION_TAKE_CONTROLS is revoked and scripts immediately stop. That definitely happens if a scripted object is detached, maybe the same applies to un-sitting. Also, I just remembered, the important thing to do is not just get PERMISSION_TAKE_CONTROLS but to actually call llTakeControls(CONTROL_FWD, TRUE, TRUE); then your script will ignore no-script settings.
  5. Ok I'm a dummy, because I KNEW THIS ANSWER lol. Scripts are only actually disabled below a certain altitude. I'm doing all my testing in a skybox... where scripts always run. Duh! So yes, on the ground, that setting DOES WORK in all cases, attachment or not. I forget what the cutoff altitude is... Attachments follow the same rule I believe. To elaborate on what you said, just get PERMISSION_TAKE_CONTROLS permission and your scripts will not stop running if you enter a no-script area (I believe with the exception that if scripts are disabled for the entire region, NO SCRIPTS run, period).
  6. Yes it doesn't matter whether the default script is attached or not. In fact the old trick of allowing scripts to run in non-script areas ONLY works for attached scripts but in my test case I'm rezzing a fresh prim and default script on the ground. Picking it up and re-rezzing it makes no difference, neither does relogging to refresh permission checks.
  7. I've always been a bit baffled by the "run scripts" parcel option. Set up a parcel with all permissions on (Options tab) EXCEPT run scripts for everyone. Leave group scripts on so your stuff still works! I'm doing this testing in an LL region. Bring in an avatar that is NOT in the land group. Verify that the avatar can see the tiny icon on the top bar that shows that scripts are disabled. Using that avatar, rez a box on the ground, create a default script. Verify that the box is NOT tagged with any group. Don't edit it. Touch the box. The script is obviously running. Why? What exactly does "disabled" mean here? Nothing? I've tested this on my parcel with an alt that is in NO groups, no special permissions, nothing. How can this avatar run scripts on a parcel where this permission is disabled? What am I missing here?
  8. If you look at the sample code I posted, you'll see that this is a completely different scenario. The web "server" is an LSL http_request() event. But yes I already allow the LL certificate in https requests from LSL scripts to my actual web server, so no problem there.
  9. That seems to be the sensible path at this point... ugh. The non-SSL warning just looks scary to cusomters, like I'm doing something insecure, I hate that.
  10. I appreciate the solution of "just post to your web server" but you have no idea how much work that will be to re-architect how that data is processed from a script to the web server, that means a complete port of all that code, and there are other complications I didn't mention that simply make that a ton of work. It's ooooold but super stable code. The form is served from from the website but simply posts directly to an LSL script. Seemed like a cool idea at the time, lol. Just post all that data to the script and boom, the script has all that data. The real question is that doggone self-signed certificate not being recognized by the web browsers. I'm not a deep expert on certificates and how web browsers use them, but can't LL just... use a non-self-signed certificate for that? Would that fix the problem?
  11. For historical reasons (compatibility) I am submitting a HTML form (from a browser) directly to an inworld script via HTTP, by setting the HTML action attribute in the form tag to the inworld script's URL. I'm experimenting getting everything switched over to HTTPS due to the fact that web browsers are now warning when submitting forms to a non-https address. The big problem I've run into is that the LL certificate that inworld scripts use is self-signed and not accepted by Firefox and Chrome (ERR_CERT_AUTHORITY_INVALID). This is quite easy to see, just create a script: default { state_entry() { llRequestSecureURL(); } http_request(key id, string method, string body) { llOwnerSay(body); } } Then just paste that URL into your web browser and you'll see the security error. As a side note I'm also making http requests directly from my web server to inworld objects and THAT works fine since I can control the certificate validation process and approve it. LL makes that cert available for download for that purpose which is great. But I can't control the same cert validation process in all web browsers so I'm stuck. The better solution which I've used ever since then is to never submit forms directly to inworld objects. Instead submit to your web host as usual, process the data, then send whatever data you need to the inworld script with an http(s) request or some other method. Plus processing large, complex forms can eat up all your script memory in a hurry. But this is a major rewrite of the code which I'd rather avoid as it's very bug free and working just fine. I think I'm screwed... and a ton of code needs to be redone as it's a pretty complex form that requires a lot of processing and more importantly, this will completely break compatibility with updates in the future. Please tell me I'm wrong...
  12. Looks like the email problem is fixed, I sent an email to an inworld script and it arrived after just a few seconds. Back to normal, whew
  13. https://jira.secondlife.com/browse/BUG-231843 There definitely is a problem, they are still trying to fix it.
  14. I woke up this morning to find all the incoming emails have arrived. It looks like they have been delayed about eight hours. My guess is that someone noticed the problem already, fixed it, and the mail server is working through a serious backlog. I filed a jira but there’s no activity on it.
  15. Can someone confirm this? All emails from external sources are not arriving at my scripts, regardless of region, as of a day or two ago. Here's a test script, try emailing the script manually (using the key@lsl.secondlife.com address) with a non-blank subject line and see if anything arrives at all... is it just me?? object-to-object scripts are working fine. Only external emails are failing 100% just recently. getKey() { llOwnerSay("My key is " + (string)llGetKey()); } default { state_entry() { getKey(); llGetNextEmail("", ""); llSetTimerEvent(5); } touch_start(integer touches) { getKey(); llGetNextEmail("", ""); } email(string time, string address, string subj, string message, integer num_left) { llOwnerSay(subj); if (num_left > 0) llGetNextEmail("", ""); } timer() { llGetNextEmail("", ""); } }
  16. OK thank you, the avatar in question as of the 18th (5-ish days after changing his name) it was still not updated (old name in HTTP headers). So we just have to wait until the RC is deployed to the production servers, it looks like. Thanks much for the info.
  17. OK thanks for the info. Can you give me some more details on the bug, I am getting a "You can't view this issue" message when I search on that at jira.secondlife.com. Or is there another way to view that bug?
  18. If I have an avatar that recently changed their name and give them a scripted object that calls llKey2Name(llGetOwner()), it works correctly (it returns their new name). However if the same object sends an HTTP request, llGetHTTPHeader(ID, "x-secondlife-owner-name") returns their OLD name. Is this just a timing issue, are these two methods of getting a legacy name going to be in sync some time soon? I'm assuming that's the case... I don't know exactly when the avatar in question changed their name.
  19. Yeah it's so rare that bombarding my server with umpteen million of the same POSTs for a few months seems like a long shot. I definitely can't even imagine how to reproduce them on demand. I can't see a pattern - in frequency, or the position of truncation, or the originating script name, or region.. but I just realized I've been lax on saving these records for very long so I'll see if there's any kind of date/time pattern, thanks for the suggestion. Don't have enough data to rule that out...
  20. That's a great thought. But in this case, that's not happening. Sometimes the truncation happens right in the middle of a hard-coded parameter name rather than something I'm pulling from the database. And those parameter names don't have any special characters in them. For example in the middle of the string I have "param1=customer_name" or something and it truncates right in the middle of "param1". I've gone over and over my LSL code that's making the HTTP call thinking it must be truncating it here, and that's always a valid possibility, but I really don't think so. I probably get a half million HTTP requests per week and only a few get chopped up like this. And again, I might get two in a row, truncated in different positions on what is almost an identical data string, coming from different scripts in different regions so... I really do not suspect a script bug. The only thing that could affect two http calls from two different scripts like that is not the script itself but something in between the sender script and the receiving website where the data is corrupted.
  21. Sorry I should have noted that the maxlength is far, far beyond the small number of characters where the truncation is happening. by default of course it's 2k and I'm never setting it to less than 2K, ever. I realize this is really a shot in the dark, I'm just so stuck, I really think it's not my code/server. But never say never, I know that all too well. I just wonder if anyone else has ever seen this happening, is it just me? And I should have noted that ALL the requests are coming from my own scripts so I know exactly what is going on, on both ends. The reqests are nothing special... and umpteen zillion of them work just fine with no errors until it glitches once in a blue moon. llHTTPRequest(URL, [HTTP_METHOD, "POST", HTTP_MIMETYPE, "application/x-www-form-urlencoded", HTTP_VERBOSE_THROTTLE, FALSE], postdata); Where URL is my web server where I'm logging the errors. Just for fun here's the full error report for a typical truncation error event. Note that the expected form value for this particular API should look something sorta like: "source=subscribers2&groupname=blahdeblah&mode=subscriber&owner_key=a30b48f3-ecc2-4004-b5a2-fc1f26ef344x" But it's chopping it off right at the beginning of "groupname". So it's a hard-coded parameter name... not any kind of variable... and all the rest of the params are just... gone. Then .07 seconds before this there was a very similar error but the point of truncation was different. The other APi came from a different script in a totally different region, too. So it's not some kind of region glitch. Nor is it a specific LL server glitch since the other POST came from a different server. But it could be some kind of gateway problem or something, I don't know... _____ Error count: 2 minutes since last error: 0.07685149 Base Exception: System.ArgumentNullException System.Web.HttpUnhandledException in Boolean HandleError(System.Exception) Exception of type 'System.Web.HttpUnhandledException' was thrown. HTTP code: 500 System.ArgumentNullException in Void StringToNumber(System.String, System.Globalization.NumberStyles, NumberBuffer ByRef, System.Globalization.NumberFormatInfo, Boolean) Parameter name: String Form: source=subscribers2&g POST From: sim10637.agni.lindenlab.com X-SecondLife-Object-Name: Syndicate Sunday Designer Admin X-SecondLife-Object-Key: d20e5a72-5dcc-ebdc-70bf-3bbdd003a3b1 X-SecondLife-Owner-Name: Ylva Somebody X-SecondLife-Owner-Key: x30b48f3-ecc2-4004-b5a2-fc1f26ef3441 X-Secondlife-Shard: Production http://slurl.com/secondlife/Somewhere/167/22/2996
  22. I've been plagued by a very occasional problem for a very long time now (years?) where a few HTTP POST requests from in-world to my web server get truncated. So for example I make a normal HTTPrequest() POST request from a script to my web server with data like param1=bob&param2=fred and it arrives at the server truncated, for example I might get "param1=b" or "param1=bob&pa". These cause an error on the server because required parameters are missing, so they all get logged. These result in an error 499 returning to the script inworld. Since I typically have lots of http requests coming in, I'll get these in very small batches, maybe 2-3 over the course of just a few milliseconds, sometimes it might be the same API call and the location of the truncation in the post data appears to be pretty random. I might get two identical API calls a few ms apart that are truncated, but at different positions in the data. It isn't related to a particular API, it happens to all of them, but there are a few that get called far, far more than others so naturally the distribution is weighted toward those heavily called APIs. These are extremely occasional, maybe I'll get a batch of 1-3 all within a few milliseconds, a week apart, or two weeks or who knows. Considering I'm getting maybe 1 HTTP request per second (some GETs, mostly POSTs) from in world scripts, pretty much 24x7, over the course of a week that's a lot of perfectly fine requests until another little batch of truncated requests comes in. Has anyone else seen anything like this that's logging bad HTTP calls at the web server level? I just don't see any pattern to these mystery truncations. It's not a huge issue but it's been nagging me for ages and I just wonder what is going on. I'm convinced it's some kind of LL server glitch and they are being sent truncated. I've never seen this happen to any HTTP requests other than from an inworld LSL script. I really don't think it's an issue with my web server (Azure web app), but hey you never know. But I heavily suspect they are being sent truncated.
  23. OK I think I have a good handle on how this affects me and my various systems and scripts. But I have one super vital question: will search in the viewer work with retired (historical) names? Will it find the correct avatar, even with their old names? Same question for https://search.secondlife.com/ but that is much less important to me.
×
×
  • Create New...