Jump to content

Nelson Jenkins

Resident
  • Posts

    34
  • Joined

  • Last visited

Reputation

1 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Managed to finally figure out how to get wiki editing access and have added the results of my experimentation (from what I read in this thread, pretty much what everyone else did upon finding this amazing new feature). Mostly in llLinksetDataWrite. Also added some example snippets, one of which seems to semi-reliably prevent data tampering, or at least gives a good starting point to do so. Have already successfully incorporated LSD into a couple of projects that have been sitting around waiting for me to put the effort in to build some web services to mostly-permanently store configuration data without notecards (soooo 2006!) I noticed earlier that the Protected functions were incurring exactly an undocumented 0.5s delay but as of this week they don't seem to anymore? I assumed this was due to some sort of time-based hashing algorithm. Why, I have no idea, considering there is no real reason to encrypt the data on-server. I'm not totally up to speed yet on the wiki's arcane templates so someone else will have to add the control character rezzing bug, though hopefully since this stuff is fresh it will be quickly and quietly fixed...
  2. As long as tokens cannot be traded for cash or anything of value, it is OK at any rating.
  3. Closing the conversations window still closes all child conversation windows. Then, if you minimize the main conversations window, it can't be resized, yet only 1/3rd of horizontal space is actually used for icons. That is a complete game killer for me, I don't want that window to constantly be on the screen. Still don't need the "Blocked" tab in the people window; I can just as well go to the Communicate menu and see that information separately without having to keep my people window an extra 120px wider all the time.
  4. I have discovered yet another problem. Dreamweaver forces another frame: <frameset rows="*,*" border="0" framespacing="0" frameborder="0"> <frame src="loginform.php" border="0" scrolling="auto" marginwidth="0" marginheight="0"> <frame src="UntitledFrame-1"></frameset> <noframes>You need a browser with frames support to access BluComm.</noframes> This is apparently what caused the messed up scrollbar. If I just revert the change, it doesn't seem to do it again. Still have to change my $_GET variables to something else since it seems to lose them, but so far frameset is working, iframe just doesn't work at all. Thanks a lot for the help, think it's settled now.
  5. The problem exists outside of SL (specifically Chrome). Both methods have problems that aren't related to SL/non-SL browsing.
  6. I'm aware of the fixed size limitations, and that's not the problem here. There is something going wrong with both the frameset and the iframe approaches where 100% height and width are constrained to a small box. The site is designed for both general browser and MOAP viewing, so a fixed-size iframe would not be appropriate here.
  7. I'm using a default PHP install, and to my knowledge I'm storing session information on the server (certainly not sending session IDs through the URL). Also, I've run into a problem with frames. frameset works, but if the content is longer than the browser height, I can't scroll. If I enable scrolling, if the content is shorter than the browser height, the frame is not the full length of the screen, and the CSS gets cut off and vertical centering is broken. If I use iframes, it fixes the scrolling problem, but there is a white border around the frame and it's limited to maybe the top 20% of the page. Here's the code for the index page: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html><head><title>BluComm RMS</title></head><body> <iframe src="loginform.php" width="100%" height="100%" frameborder="0" marginwidth="0" marginheight="0"> You need a browser with frames support to access BluComm. </iframe></body></html> Here's what shows up: http://blucomm.gentektechnologies.com/ Should look more like this: http://blucomm.gentektechnologies.com/loginform.php Any ideas?
  8. Right, looking good! Seems to circumvent shared redirection, as far as I can tell. Also, while I'm at it, I'm using a simple IF statement for the logged-in check, but there has to be a more efficient way of doing this. Help on this as well? Here's the code, basically: if ($_SESSION['user']=='') { echo "<meta http-equiv='refresh' content='0;url=http://logoutpage.example'></body></html>"; } else { echo "(the rest of the page content, which is rather long so I just cut it out)"; }
  9. Makes sense, but how would I render different pages in that case? I don't have just one .php file that they need to browse around. Additionally, if the browser navigates to a different page (by means of form submission or clicking a link), would it not redirect outside of the frame as well, and change the URL? /not_a_web_developer
  10. No, everything is server-side (I don't actually have any LSL at this point, just set the MOAP manually to the login page and go from there). Here's some sorta-pseudo-code to make it easier to understand: login.php if (<login correct>) { $_SESSION['user']=$username; <redirect to dashboard> } dashboard.php if ($_SESSION['user']=='') { <redirect to login page> } else { <render dashboard> } Again, when avatar 1 is playing with dashboard.php and avatar 2 pops in and loads the page in their client, they get redirected back to login.php. The prim interprets this as avatar 2 changing the page from dashboard.php to login.php, and updates it for avatar 1 as well. Is there any way to avoid this redirection also redirecting avatar 1? If not, is there any way avatar 2 can still view the page without getting redirected, but can't do anything if they aren't logged in (submit forms, navigate around, etc.)? I'm aware that there are security settings for MOAP (owner/group/everyone) but I need to set it per avatar/user, not a general owner/group/everyone setting, so logging in is the only way to do it.
  11. But the problem is whenever someone views the prim while not logged in, they get redirected to the login page, which takes the original user (who IS logged in) back to the login page as well. I get where you're coming from but still don't get how you can accomplish totally, 100% separate sessions that don't share pages... because MOAP, to the best of my knowledge, forces it to be shared.
  12. I know PHP isn't LSL, but I'm assuming the biggest concentration of PHP developers would be here, so whatever. I am a totally novice PHP programmer; this is the first full site I'm developing. It's dsigned to store information which would be accessed through an in-world laptop using prim media. I don't really mind if other people view the information on the site while someone else is browsing around, but I don't want to let them submit searches or save data. To do this, I'm storing a name into the "user" session variable (SL username, to be exact, which is the site's username as well) - $_SESSION['user']=$username - and checking to make sure this variable exists whenever a page is loaded. If it doesn't exist, that means the user isn't logged in, so it redirects back to the login page (otherwise it just shows the page). The problem with this approach is MOAP is "shared", so if just one person is using it, it's fine - but if someone else loads the page, it'll redirect them to the login page, which the prim will recognize and refresh for the original user as well, logging them out immediately. I tried to do the login check only if a link was clicked or a form was submitted, but then people would just try to nagivate themselves and end up logging everyone out anyway . Is there a better approach to this? Ideally, I'd like each instance of the MOAP to be totally separate so this shared-logout nonsense doesn't cause problems. I've seen a lot of people have trouble logging in to a lot of other sites as well, so I'm not sure this is easily fixable without Linden Lab magically implementing non-shared MOAP.
  13. There is really nothing wrong with ticking "remember", as most modern browsers encrypt password storage, IIRC. Passwords aren't stored plaintext on websites anyway, unless the webmaster is a complete idiot, so unless someone else is using your computer there's very little security risk.
  14. "My personal wish would be to get rid of the whole review system, since there are too many new and/or stupid customers arounds, yes I've said it!" I don't think the review system does more harm than good. I know I tend to get comfy buying a product that at least has a 3-4 star rating instead of one with no rating at all. It at least means someone bought it and used it. Now that sales ranks don't exist (for what I can tell), it's impossible to tell if something has actually sold before, or if it's just a piece of junk.
  15. I was mainly talking about llGiveInventory failing, not the box itself. That is a problem as well, yes, but easy to fix - llGiveInventory failure is probably not as easy and virtually undetectable until llTransferInventory shows up, so we would need a way to filter out those bad reviews or an easier way to delete them than sit around waiting for a ticket response. (fwiw, I have not gotten a response to a support ticket or even abuse report in at least the past 2 years)
×
×
  • Create New...